CVE-2022-50833 in Linux
Summary
by MITRE • 12/30/2025
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: use hdev->workqueue when queuing hdev->{cmd,ncmd}_timer works
syzbot is reporting attempt to schedule hdev->cmd_work work from system_wq WQ into hdev->workqueue WQ which is under draining operation [1], for
commit c8efcc2589464ac7 ("workqueue: allow chained queueing during destruction") does not allow such operation.
The check introduced by commit 877afadad2dce8aa ("Bluetooth: When HCI work queue is drained, only queue chained work") was incomplete.
Use hdev->workqueue WQ when queuing hdev->{cmd,ncmd}_timer works because
hci_{cmd,ncmd}_timeout() calls queue_work(hdev->workqueue). Also, protect
the queuing operation with RCU read lock in order to avoid calling queue_delayed_work() after cancel_delayed_work() completed.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 04/25/2026
The vulnerability CVE-2022-50833 represents a critical race condition and workqueue management issue within the Linux kernel's Bluetooth subsystem that could lead to system instability and potential denial of service conditions. This flaw specifically affects the handling of Bluetooth device workqueue operations during the shutdown and draining process of HCI (Host Controller Interface) workqueues. The issue stems from improper queuing of timer-based work items that are scheduled during the workqueue destruction phase, creating a scenario where system_wq attempts to schedule work into a workqueue that is already under draining operations.
The technical root cause involves the improper management of workqueue operations in the Bluetooth subsystem where the hdev->cmd_work and hdev->ncmd_work timer events are being scheduled incorrectly. When the HCI workqueue undergoes the draining process, the kernel's workqueue subsystem enforces strict rules to prevent queuing operations into workqueues that are being destroyed or drained. The commit c8efcc2589464ac7 introduced changes that explicitly prevent such operations, but the existing code failed to properly utilize the device-specific workqueue (hdev->workqueue) for scheduling timer-related work items. This mismanagement occurs because the code was attempting to schedule work items using the system workqueue (system_wq) while the device-specific workqueue was in a draining state, violating kernel workqueue management principles.
The operational impact of this vulnerability is significant as it can lead to kernel oops, system crashes, or denial of service conditions when Bluetooth devices are being shut down or when the system attempts to manage Bluetooth workqueue operations during system transitions. The vulnerability manifests when syzbot, an automated bug finder, detects attempts to schedule work items from the system workqueue into a workqueue that is under destruction, which violates the kernel's workqueue subsystem integrity. This type of race condition can be exploited by malicious actors to cause system instability or may occur during normal system operation when multiple threads attempt to manage Bluetooth device states simultaneously, particularly during shutdown sequences or device disconnection events.
The vulnerability aligns with CWE-367: Time-of-Check to Time-of-Use (TOCTOU) and CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization, as it represents a race condition where workqueue operations are not properly synchronized during the workqueue destruction phase. From an ATT&CK framework perspective, this vulnerability could be leveraged for privilege escalation or denial of service attacks through the exploitation of kernel memory management flaws, potentially allowing adversaries to disrupt system services or gain unauthorized access to system resources. The fix implemented addresses this by ensuring that hci_cmd_timeout() and hci_ncmd_timeout() functions use the device-specific workqueue (hdev->workqueue) instead of attempting to queue work through the system workqueue, thereby maintaining proper workqueue hierarchy and preventing the invalid scheduling operations.
The mitigation strategy involves ensuring that timer-based work items are always scheduled using the device-specific workqueue rather than attempting to use the system workqueue during critical phases of workqueue management. The solution also incorporates proper synchronization mechanisms using RCU read locks to prevent race conditions between cancel_delayed_work() and queue_delayed_work() operations, which is essential for maintaining kernel stability during concurrent access scenarios. This fix directly addresses the incomplete check introduced by commit 877afadad2dce8aa that was meant to handle workqueue draining but failed to account for the specific timer work queuing scenarios in the Bluetooth subsystem. The implementation requires careful consideration of workqueue lifecycle management and proper synchronization to prevent similar issues in other kernel subsystems that may exhibit similar race conditions during workqueue destruction or draining operations.