Description

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix UAF in l2cap_le_connect_rsp l2cap_le_connect_rsp() obtains a channel via __l2cap_get_chan_by_ident() but neither holds a reference nor uses l2cap_chan_hold_unless_zero() before locking and operating on it. A concurrent l2cap_chan_del() triggered by a remote disconnect can free the channel between the lookup and l2cap_chan_lock(), causing a use-after-free. The BR/EDR counterpart l2cap_connect_rsp() and the sibling handler l2cap_le_command_rej() already use l2cap_chan_hold_unless_zero() to safely hold a reference, but l2cap_le_connect_rsp() was left unprotected. Fix by adding l2cap_chan_hold_unless_zero() after the ident lookup and l2cap_chan_put() on the exit path, consistent with other L2CAP response handlers.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-08-15T13:17:59.337Z",
  "pubdate": "2026-08-15T13:17:59.337Z",
  "executiveSummary": "A use-after-free (UAF) vulnerability exists in the Linux kernel's Bluetooth subsystem within the L2CAP layer, specifically in the l2cap_le_connect_rsp function.\nThis vulnerability is classified as a use-after-free flaw, which can lead to denial of service, memory corruption, or potentially arbitrary code execution.\nThe vulnerability affects the Linux kernel Bluetooth implementation across systems utilizing Low Energy (LE) L2CAP connection response handling.\nRisk implications include potential kernel panics, system instability, or compromise of the underlying operating system depending on memory layout and exploitation complexity.\nAn attacker must be capable of interacting with the target over the Bluetooth stack, typically within local radio range or via connected interface vectors.\nExploitation requires precise timing to trigger a concurrent remote disconnect and channel deletion during the connection response processing window.",
  "technicalDetails": "The root cause of the vulnerability lies in improper reference counting and synchronization within l2cap_le_connect_rsp().\nDuring execution, l2cap_le_connect_rsp() obtains an L2CAP channel pointer via __l2cap_get_chan_by_ident() based on the transaction identifier.\nHowever, the function fails to hold a reference to the channel or utilize l2cap_chan_hold_unless_zero() before acquiring the channel lock and performing operations on the data structure.\nA race condition occurs when a concurrent l2cap_chan_del(), triggered by a remote disconnect event, is processed by the system.\nThis asynchronous disconnection can free the channel memory between the initial lookup in __l2cap_get_chan_by_ident() and the subsequent acquisition in l2cap_chan_lock().\nConsequently, the execution flow attempts to access the deallocated memory block, resulting in a classic use-after-free condition.\nThe vulnerable component is the L2CAP implementation in the Linux kernel Bluetooth subsystem, specifically l2cap_le_connect_rsp().\nUnlike the BR/EDR counterpart l2cap_connect_rsp() and sibling handler l2cap_le_command_rej(), which correctly implement l2cap_chan_hold_unless_zero() for safe reference management, l2cap_le_connect_rsp() was left unprotected.\nNetwork exposure is inherent to the Bluetooth stack, allowing remote entities within proximity to interact with the L2CAP layer.\nAuthentication and privilege requirements depend on the specific Bluetooth profile and pairing state, though certain control messages may be processed prior to full authentication.\nStep-by-step exploitation involves an attacker initiating or maintaining a Low Energy connection, sending a crafted sequence or timing a remote disconnect precisely as the local stack processes an l2cap_le_connect_rsp message, thereby invalidating the channel reference mid-flight and corrupting kernel heap memory upon subsequent dereference."
}