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.
CVSS
8.8 HIGH (v3.1, CNA)CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
from 3df91ea20e744344100b10ae69a17211fcf5b207 before 3634cbdc2eb414b69ffa752ddbe5e0458518e321; from 3df91ea20e744344100b10ae69a17211fcf5b207 before e1c100e2d61bd8c718b7d91fe3e050780a9bf72d; from 3df91ea20e744344100b10ae69a17211fcf5b207 before deb8493a8fa599f6c95e2465b12bfdfb7f94a1d9; from 3df91ea20e744344100b10ae69a17211fcf5b207 before 89dec92041717b027216e110599e4f6d6c921b79; from 3df91ea20e744344100b10ae69a17211fcf5b207 before 50dfec218808b148ab4247b1858031b7a32015c5; from 3df91ea20e744344100b10ae69a17211fcf5b207 before 859d3ace791ed878ae9ba5522c7844d960da8f88; from 3df91ea20e744344100b10ae69a17211fcf5b207 before 7555fd885a0603f50e49a655850a1f2bd8a25398; from 3df91ea20e744344100b10ae69a17211fcf5b207 before 8c8e620467a7b51562dbcefbd1f09f288d7d710d
from 3.4 before 5.10.259; from 5.11 before 5.15.210; from 5.16 before 6.1.176; from 6.2 before 6.6.143; from 6.7 before 6.12.93; from 6.13 before 6.18.35; from 6.19 before 7.0.12; 7.1; and 4 more ranges
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.
Printed from infosecsignals.com. Every record links back to the agency that published it.
Your cookie choices
We use essential cookies to run this site, and, only with your consent, an advertising cookie from Google to measure whether our ads lead to sign-ups and subscriptions. See our for details.