Bluetooth: hci_sync: annotate data-races around hdev->req_status
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 4.20, 5.1, 5.2, 6.6.145, 6.12.83, and 2 more
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: annotate data-races around hdev->req_status __hci_cmd_sync_sk() sets hdev->req_status under hdev->req_lock: hdev->req_status = HCI_REQ_PEND; However, several other functions read or write hdev->req_status without holding any lock: • hci_send_cmd_sync() reads req_status in hci_cmd_work (workqueue) • hci_cmd_sync_complete() reads/writes from HCI event completion • hci_cmd_sync_cancel() / hci_cmd_sync_cancel_sync() read/write • hci_abort_conn() reads in connection abort path Since __hci_cmd_sync_sk() runs on hdev->req_workqueue while hci_send_cmd_sync() runs on hdev->workqueue, these are different workqueues that can execute concurrently on different CPUs. The plain C accesses constitute a data race. Add READ_ONCE()/WRITE_ONCE() annotations on all concurrent accesses to hdev->req_status to prevent potential compiler optimizations that could affect correctness (e.g., load fusing in the wait_event condition or store reordering).
Timeline
- CVE published
- Record last updated
Affected versions
- Linux Linux
From 4.19.47 · fixed in 4.20; From 5.0.20 · fixed in 5.1; From 5.1.6 · fixed in 5.2
- Linux Linux
5.2
- KernelLinux
From 5.2.0 · fixed in 6.6.145; From 6.7.0 · fixed in 6.12.83; From 6.13.0 · fixed in 6.18.24; From 6.19.0 · fixed in 6.19.14