CVE-2022-50166
Severity CVSS v4.0:
Pending analysis
Type:
Unavailable / Other
Publication date:
18/06/2025
Last modified:
18/06/2025
Description
In the Linux kernel, the following vulnerability has been resolved:<br />
<br />
Bluetooth: When HCI work queue is drained, only queue chained work<br />
<br />
The HCI command, event, and data packet processing workqueue is drained<br />
to avoid deadlock in commit<br />
76727c02c1e1 ("Bluetooth: Call drain_workqueue() before resetting state").<br />
<br />
There is another delayed work, which will queue command to this drained<br />
workqueue. Which results in the following error report:<br />
<br />
Bluetooth: hci2: command 0x040f tx timeout<br />
WARNING: CPU: 1 PID: 18374 at kernel/workqueue.c:1438 __queue_work+0xdad/0x1140<br />
Workqueue: events hci_cmd_timeout<br />
RIP: 0010:__queue_work+0xdad/0x1140<br />
RSP: 0000:ffffc90002cffc60 EFLAGS: 00010093<br />
RAX: 0000000000000000 RBX: ffff8880b9d3ec00 RCX: 0000000000000000<br />
RDX: ffff888024ba0000 RSI: ffffffff814e048d RDI: ffff8880b9d3ec08<br />
RBP: 0000000000000008 R08: 0000000000000000 R09: 00000000b9d39700<br />
R10: ffffffff814f73c6 R11: 0000000000000000 R12: ffff88807cce4c60<br />
R13: 0000000000000000 R14: ffff8880796d8800 R15: ffff8880796d8800<br />
FS: 0000000000000000(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000<br />
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br />
CR2: 000000c0174b4000 CR3: 000000007cae9000 CR4: 00000000003506e0<br />
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br />
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br />
Call Trace:<br />
<br />
? queue_work_on+0xcb/0x110<br />
? lockdep_hardirqs_off+0x90/0xd0<br />
queue_work_on+0xee/0x110<br />
process_one_work+0x996/0x1610<br />
? pwq_dec_nr_in_flight+0x2a0/0x2a0<br />
? rwlock_bug.part.0+0x90/0x90<br />
? _raw_spin_lock_irq+0x41/0x50<br />
worker_thread+0x665/0x1080<br />
? process_one_work+0x1610/0x1610<br />
kthread+0x2e9/0x3a0<br />
? kthread_complete_and_exit+0x40/0x40<br />
ret_from_fork+0x1f/0x30<br />
<br />
<br />
To fix this, we can add a new HCI_DRAIN_WQ flag, and don&#39;t queue the<br />
timeout workqueue while command workqueue is draining.