CVE-2026-53358
UnknownSummary
In the Linux kernel, a vulnerability in the Bluetooth L2CAP subsystem was found where improper lock ordering in cleanup_listen() could cause a deadlock. Instead of calling l2cap_chan_close() directly, channels are now closed asynchronously using a timer to avoid lock inversion.
Risk Assessment
This vulnerability could lead to a kernel deadlock, causing system unresponsiveness or Bluetooth service failure, impacting device stability and availability.
Recommendation
Immediately update the Linux kernel to a version containing the fix (commit addressing the issue). Monitor official security advisories from your Linux distribution.
Original NVD description (English source)
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.