Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[PW_SID:912974] Bluetooth: btusb: avoid NULL pointer defereference in skb_dequeue() #2601

Open
wants to merge 2 commits into
base: workflow
Choose a base branch
from

Conversation

BluezTestBot
Copy link
Owner

The WCN7851 (0489:e0f3) Bluetooth controller supports firmware crash dump
collection through devcoredump. During this process, the crash dump data
is queued to a dump queue as skb for further processing.

A NULL pointer dereference occurs in skb_dequeue() when processing the
dump queue due to improper return value handling:

[ 93.672166] Bluetooth: hci0: ACL memdump size(589824)

[ 93.672475] BUG: kernel NULL pointer dereference, address: 0000000000000008
[ 93.672517] Workqueue: hci0 hci_devcd_rx [bluetooth]
[ 93.672598] RIP: 0010:skb_dequeue+0x50/0x80

The issue stems from handle_dump_pkt_qca() returning the wrong value on
success. It currently returns the value from hci_devcd_init() (0 on success),
but callers expect > 0 to indicate successful dump handling. This causes
hci_recv_frame() to free the skb while it's still queued for dump
processing, leading to the NULL pointer dereference when hci_devcd_rx()
tries to dequeue it.

Fix this by:

  1. Extracting dump packet detection into new is_dump_pkt_qca() function
  2. Making handle_dump_pkt_qca() return 0 on success and negative errno
    on failure, consistent with other kernel interfaces

This prevents premature skb freeing by ensuring proper handling of dump packets.

Fixes: 20981ce ("Bluetooth: btusb: Add WCN6855 devcoredump support")
Signed-off-by: En-Wei Wu [email protected]

drivers/bluetooth/btusb.c | 75 ++++++++++++++++++++++++---------------
1 file changed, 47 insertions(+), 28 deletions(-)

tedd-an and others added 2 commits November 26, 2024 16:28
This patch adds workflow files for ci:

[sync.yml]
 - The workflow file for scheduled work
 - Sync the repo with upstream repo and rebase the workflow branch
 - Review the patches in the patchwork and creates the PR if needed

[ci.yml]
 - The workflow file for CI tasks
 - Run CI tests when PR is created

Signed-off-by: Tedd Ho-Jeong An <[email protected]>
The WCN7851 (0489:e0f3) Bluetooth controller supports firmware crash dump
collection through devcoredump. During this process, the crash dump data
is queued to a dump queue as skb for further processing.

A NULL pointer dereference occurs in skb_dequeue() when processing the
dump queue due to improper return value handling:

[ 93.672166] Bluetooth: hci0: ACL memdump size(589824)

[ 93.672475] BUG: kernel NULL pointer dereference, address: 0000000000000008
[ 93.672517] Workqueue: hci0 hci_devcd_rx [bluetooth]
[ 93.672598] RIP: 0010:skb_dequeue+0x50/0x80

The issue stems from handle_dump_pkt_qca() returning the wrong value on
success. It currently returns the value from hci_devcd_init() (0 on success),
but callers expect > 0 to indicate successful dump handling. This causes
hci_recv_frame() to free the skb while it's still queued for dump
processing, leading to the NULL pointer dereference when hci_devcd_rx()
tries to dequeue it.

Fix this by:

1. Extracting dump packet detection into new is_dump_pkt_qca() function
2. Making handle_dump_pkt_qca() return 0 on success and negative errno
   on failure, consistent with other kernel interfaces

This prevents premature skb freeing by ensuring proper handling of dump packets.

Fixes: 20981ce ("Bluetooth: btusb: Add WCN6855 devcoredump support")
Signed-off-by: En-Wei Wu <[email protected]>
Copy link

CheckPatch
Desc: Run checkpatch.pl script
Duration: 0.40 seconds
Result: PENDING

Copy link

GitLint
Desc: Run gitlint
Duration: 0.26 seconds
Result: PENDING

Copy link

SubjectPrefix
Desc: Check subject contains "Bluetooth" prefix
Duration: 0.07 seconds
Result: PASS

Copy link

BuildKernel
Desc: Build Kernel for Bluetooth
Duration: 27.79 seconds
Result: PASS

Copy link

CheckAllWarning
Desc: Run linux kernel with all warning enabled
Duration: 27.28 seconds
Result: PASS

Copy link

CheckSparse
Desc: Run sparse tool with linux kernel
Duration: 30.84 seconds
Result: PASS

Copy link

BuildKernel32
Desc: Build 32bit Kernel for Bluetooth
Duration: 24.73 seconds
Result: PASS

Copy link

TestRunnerSetup
Desc: Setup kernel and bluez for test-runner
Duration: 436.57 seconds
Result: PASS

Copy link

TestRunner_l2cap-tester
Desc: Run l2cap-tester with test-runner
Duration: 20.37 seconds
Result: PASS

Copy link

TestRunner_iso-tester
Desc: Run iso-tester with test-runner
Duration: 26.54 seconds
Result: FAIL
Output:

WARNING: possible circular locking dependency detected
Total: 124, Passed: 120 (96.8%), Failed: 0, Not Run: 4

Copy link

TestRunner_bnep-tester
Desc: Run bnep-tester with test-runner
Duration: 4.77 seconds
Result: PASS

Copy link

TestRunner_mgmt-tester
Desc: Run mgmt-tester with test-runner
Duration: 119.84 seconds
Result: PASS

Copy link

TestRunner_rfcomm-tester
Desc: Run rfcomm-tester with test-runner
Duration: 7.59 seconds
Result: PASS

Copy link

TestRunner_sco-tester
Desc: Run sco-tester with test-runner
Duration: 9.31 seconds
Result: PASS

Copy link

TestRunner_ioctl-tester
Desc: Run ioctl-tester with test-runner
Duration: 8.07 seconds
Result: PASS

Copy link

TestRunner_mesh-tester
Desc: Run mesh-tester with test-runner
Duration: 6.12 seconds
Result: FAIL
Output:

Total: 10, Passed: 9 (90.0%), Failed: 1, Not Run: 0

Failed Test Cases
Mesh - Send cancel - 2                               Failed       0.116 seconds

Copy link

TestRunner_smp-tester
Desc: Run smp-tester with test-runner
Duration: 6.98 seconds
Result: PASS

Copy link

TestRunner_userchan-tester
Desc: Run userchan-tester with test-runner
Duration: 4.96 seconds
Result: PASS

Copy link

IncrementalBuild
Desc: Incremental build with the patches in the series
Duration: 0.96 seconds
Result: PENDING

@github-actions github-actions bot force-pushed the workflow branch 4 times, most recently from 5f4eabb to b9a334a Compare December 5, 2024 16:58
@github-actions github-actions bot force-pushed the workflow branch 3 times, most recently from 4db90f9 to 710fda9 Compare December 12, 2024 21:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants