CVE-2026-63976 in Linux
Summary
by MITRE • 07/19/2026
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: l2cap: clear chan->ident on ECRED reconfiguration success
l2cap_ecred_reconf_rsp() returns early on success without clearing chan->ident. Every other L2CAP response handler (l2cap_ecred_conn_rsp, l2cap_le_connect_rsp, l2cap_config_rsp) clears chan->ident after a successful transaction to prevent the channel from matching subsequent responses with the recycled ident value.
A remote attacker that completed a reconfiguration as the peer can replay a failure response with the stale ident, causing the kernel to match and destroy the already-established channel via l2cap_chan_del(chan, ECONNRESET).
Clear chan->ident for all matching channels on success, and harden the failure path by using l2cap_chan_hold_unless_zero() consistent with other L2CAP handlers (l2cap_le_command_rej, __l2cap_get_chan_by_ident).
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/19/2026
This vulnerability exists within the Linux kernel's Bluetooth implementation, specifically in the L2CAP (Logical Link Control and Adaptation Protocol) layer responsible for managing Bluetooth connections. The flaw resides in how the l2cap_ecred_reconf_rsp() function handles successful channel reconfiguration operations. When a remote attacker successfully completes a reconfiguration process as a peer device, they can exploit this vulnerability by replaying a previously failed response message with a stale identifier value. This particular issue stems from the function's failure to clear the chan->ident field upon successful completion of the reconfiguration process, creating a scenario where subsequent responses could match against recycled identifier values.
The technical implementation flaw occurs because l2cap_ecred_reconf_rsp() returns early when successful without clearing the channel identifier field, unlike other L2CAP response handlers such as l2cap_ecred_conn_rsp, l2cap_le_connect_rsp, and l2cap_config_rsp which properly clear chan->ident after successful transactions. This inconsistency creates a predictable vulnerability where an attacker can manipulate the kernel's channel management system by leveraging stale identifier values to trigger unintended behavior. The vulnerability directly relates to CWE-362, which covers race conditions, and CWE-20, which addresses improper input validation in the context of Bluetooth protocol handling.
The operational impact of this vulnerability is significant as it allows a remote attacker with access to the Bluetooth communication channel to potentially disrupt established connections by causing the kernel to incorrectly match subsequent responses with recycled identifier values. When the malicious response is processed, the kernel's l2cap_chan_del() function receives an ECONNRESET signal and destroys the already-established channel, effectively causing denial of service for legitimate connection attempts. This type of attack aligns with ATT&CK technique T1499.004, which involves network disruption through manipulation of communication protocols, specifically targeting the reliability of connection management systems.
The recommended mitigations involve implementing proper identifier clearing mechanisms across all matching channels upon successful reconfiguration completion, ensuring that every channel identifier is properly reset to prevent reuse conflicts. Additionally, the implementation should harden the failure path by adopting l2cap_chan_hold_unless_zero() function calls consistently with other L2CAP handlers such as l2cap_le_command_rej and __l2cap_get_chan_by_ident. These measures align with security best practices for protocol implementation and help prevent identifier recycling vulnerabilities that could be exploited to manipulate channel state management within the kernel's Bluetooth subsystem. The fix ensures complete consistency across all L2CAP response handlers while maintaining proper reference counting mechanisms throughout the connection lifecycle management process.