-
Notifications
You must be signed in to change notification settings - Fork 1
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
base: workflow
Are you sure you want to change the base?
Conversation
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]>
CheckPatch |
GitLint |
SubjectPrefix |
BuildKernel |
CheckAllWarning |
CheckSparse |
BuildKernel32 |
TestRunnerSetup |
TestRunner_l2cap-tester |
TestRunner_iso-tester
|
TestRunner_bnep-tester |
TestRunner_mgmt-tester |
TestRunner_rfcomm-tester |
TestRunner_sco-tester |
TestRunner_ioctl-tester |
TestRunner_mesh-tester
|
TestRunner_smp-tester |
TestRunner_userchan-tester |
IncrementalBuild |
5f4eabb
to
b9a334a
Compare
4db90f9
to
710fda9
Compare
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:
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(-)