Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen()
- 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 5.10.259, 5.15.210, 6.1.176, 6.6.143, 6.12.93, 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
- Exploitation: none
- Automatable: no
- Technical impact: total
Summary
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen() l2cap_chan_close() removes the channel from conn->chan_l, which must be done under conn->lock. cleanup_listen() runs under the parent sk_lock, so acquiring conn->lock would invert the established conn->lock -> chan->lock -> sk_lock order. Instead of calling l2cap_chan_close() directly, schedule l2cap_chan_timeout with delay 0 to close the channel asynchronously. The timeout handler already acquires conn->lock and chan->lock in the correct order. The timer is only armed when chan->conn is still set: if it is already NULL, l2cap_conn_del() has already processed this channel (l2cap_chan_del + l2cap_sock_teardown_cb + l2cap_sock_close_cb), so there is nothing left to do. If l2cap_conn_del() races in after the timer is armed, __clear_chan_timer() inside l2cap_chan_del() cancels it; if the timer has already fired, the handler returns harmlessly because chan->conn was cleared.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: total
- Record last updated
Affected versions
- Linux Linux
From 3df91ea20e744344100b10ae69a17211fcf5b207 · fixed in 3634cbdc2eb414b69ffa752ddbe5e0458518e321; From 3df91ea20e744344100b10ae69a17211fcf5b207 · fixed in e1c100e2d61bd8c718b7d91fe3e050780a9bf72d; From 3df91ea20e744344100b10ae69a17211fcf5b207 · fixed in deb8493a8fa599f6c95e2465b12bfdfb7f94a1d9; From 3df91ea20e744344100b10ae69a17211fcf5b207 · fixed in 89dec92041717b027216e110599e4f6d6c921b79; From 3df91ea20e744344100b10ae69a17211fcf5b207 · fixed in 50dfec218808b148ab4247b1858031b7a32015c5; From 3df91ea20e744344100b10ae69a17211fcf5b207 · fixed in 859d3ace791ed878ae9ba5522c7844d960da8f88; From 3df91ea20e744344100b10ae69a17211fcf5b207 · fixed in 7555fd885a0603f50e49a655850a1f2bd8a25398; From 3df91ea20e744344100b10ae69a17211fcf5b207 · fixed in 8c8e620467a7b51562dbcefbd1f09f288d7d710d
- Linux Linux
3.4
- KernelLinux
From 3.4.0 · fixed in 5.10.259; From 5.11.0 · fixed in 5.15.210; From 5.16.0 · fixed in 6.1.176; From 6.2.0 · fixed in 6.6.143; From 6.7.0 · fixed in 6.12.93; From 6.13.0 · fixed in 6.18.35; From 6.19.0 · fixed in 7.0.12
References 8
git.kernel.org
- stable/c/3634cbdc2eb414b69ffa752ddbe5e0458518e321
- stable/c/e1c100e2d61bd8c718b7d91fe3e050780a9bf72d
- stable/c/deb8493a8fa599f6c95e2465b12bfdfb7f94a1d9
- stable/c/89dec92041717b027216e110599e4f6d6c921b79
- stable/c/50dfec218808b148ab4247b1858031b7a32015c5
- stable/c/859d3ace791ed878ae9ba5522c7844d960da8f88
- stable/c/7555fd885a0603f50e49a655850a1f2bd8a25398
- stable/c/8c8e620467a7b51562dbcefbd1f09f288d7d710d