Bluetooth: L2CAP: cancel pending_rx_work before taking conn->lock
- 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 3.16, 5.10.261, 5.15.212, 6.1.178, 6.6.145, and 3 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
- Exploitation: none
- Automatable: no
- Technical impact: total
Summary
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: cancel pending_rx_work before taking conn->lock l2cap_conn_del() takes conn->lock and then calls cancel_work_sync() for pending_rx_work. process_pending_rx() takes the same mutex, so teardown can deadlock against the worker it is flushing. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the l2cap_conn_ready() -> queue_work(..., &conn->pending_rx_work) submit path, the l2cap_conn_del() -> cancel_work_sync(&conn->pending_rx_work) teardown path, and the process_pending_rx() -> mutex_lock(&conn->lock) worker edge. Lockdep WARNING: possible circular locking dependency detected process_pending_rx+0x21/0x2a [vuln_msv] l2cap_conn_del.constprop.0+0x3f/0x4e [vuln_msv] *** DEADLOCK *** Cancel pending_rx_work before taking conn->lock, matching the existing lock-before-drain ordering used for the two delayed works in the same teardown path. The pending_rx queue is still purged after the work has been cancelled and conn->lock has been acquired.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: total
- Record last updated
Affected versions
- Linux Linux
From 7ab56c3a6eccb215034b0cb096e0313441cbf2a4 · fixed in fc0c3b9cf27cfa2a06f66dae1d08c668fe0a2faa; From 7ab56c3a6eccb215034b0cb096e0313441cbf2a4 · fixed in 9901f847a762a5d953871dd95767ce2aed3d684d; From 7ab56c3a6eccb215034b0cb096e0313441cbf2a4 · fixed in 4a0bb0fd63fe2b0c62e1072cd1811d6f61e0081c; From 7ab56c3a6eccb215034b0cb096e0313441cbf2a4 · fixed in 8daaf7f73fe998631a160d1a5a7e1b0b0480eef8; From 7ab56c3a6eccb215034b0cb096e0313441cbf2a4 · fixed in 8de7b386ffad480ca59222b688c94a2da8f0d805; From 7ab56c3a6eccb215034b0cb096e0313441cbf2a4 · fixed in d5616beb3355b5fca2280d796c1cf7ada4ee6551; From 7ab56c3a6eccb215034b0cb096e0313441cbf2a4 · fixed in e96fbac8d3a73b0bc165383c092a30628561d320; From 7ab56c3a6eccb215034b0cb096e0313441cbf2a4 · fixed in 2641a9e0a1dd4af2e21995470a21d55dd35e5203; From 3.15.5 · fixed in 3.16
- Linux Linux
3.16
- KernelLinux
From 3.16.0 · fixed in 5.10.261; From 5.11.0 · fixed in 5.15.212; From 5.16.0 · fixed in 6.1.178; From 6.2.0 · fixed in 6.6.145; From 6.7.0 · fixed in 6.12.97; From 6.13.0 · fixed in 6.18.39; From 6.19.0 · fixed in 7.1.4
References 8
git.kernel.org
- stable/c/fc0c3b9cf27cfa2a06f66dae1d08c668fe0a2faa
- stable/c/9901f847a762a5d953871dd95767ce2aed3d684d
- stable/c/4a0bb0fd63fe2b0c62e1072cd1811d6f61e0081c
- stable/c/8daaf7f73fe998631a160d1a5a7e1b0b0480eef8
- stable/c/8de7b386ffad480ca59222b688c94a2da8f0d805
- stable/c/d5616beb3355b5fca2280d796c1cf7ada4ee6551
- stable/c/e96fbac8d3a73b0bc165383c092a30628561d320
- stable/c/2641a9e0a1dd4af2e21995470a21d55dd35e5203