CVE-2026-31513 Overview
A stack-out-of-bounds read vulnerability has been discovered in the Linux kernel's Bluetooth L2CAP subsystem, specifically within the l2cap_ecred_conn_req() function. The vulnerability is triggered when processing malformed Enhanced Credit Based Connection Requests, allowing an attacker to cause a kernel panic via KASAN detection of out-of-bounds memory access.
The flaw was identified by Syzbot, a continuous fuzzing infrastructure for the Linux kernel. When an attacker sends a request containing more than 5 Source Channel IDs (SCIDs), the function incorrectly calculates rsp_len based on unvalidated cmd_len before performing boundary checks. This results in l2cap_send_cmd() reading beyond the allocated 18-byte pdu stack buffer.
Critical Impact
Remote attackers within Bluetooth range can trigger kernel memory disclosure or denial of service by sending crafted L2CAP Enhanced Credit Based Connection Request packets, potentially causing system crashes or information leakage.
Affected Products
- Linux kernel with Bluetooth L2CAP subsystem enabled
- Systems with Enhanced Credit Based Flow Control support
- Linux-based devices with Bluetooth connectivity
Discovery Timeline
- 2026-04-22 - CVE CVE-2026-31513 published to NVD
- 2026-04-23 - Last updated in NVD database
Technical Details for CVE-2026-31513
Vulnerability Analysis
The vulnerability exists in the l2cap_ecred_conn_req() function within the Linux kernel's Bluetooth L2CAP implementation. The function allocates a local stack buffer (pdu) designed to accommodate a maximum of 5 Source Channel IDs (SCIDs), totaling 18 bytes of storage.
When processing an Enhanced Credit Based Connection Request, the function calculates rsp_len based on the incoming cmd_len value before validating whether the number of SCIDs exceeds the L2CAP_ECRED_MAX_CID threshold. If an attacker sends a request with more than 5 SCIDs, the code correctly identifies this condition and jumps to the response label to reject the malformed packet.
However, the critical flaw is that rsp_len retains the attacker-controlled oversized value when the rejection path is taken. Subsequently, l2cap_send_cmd() is called with this inflated rsp_len, instructing it to read past the legitimate bounds of the 18-byte pdu buffer. This triggers a KASAN stack-out-of-bounds read panic, potentially exposing sensitive kernel stack memory or causing a denial of service condition.
Root Cause
The root cause is a logic error in the order of operations within l2cap_ecred_conn_req(). The rsp_len variable is assigned a value derived from unvalidated user input (cmd_len) before the boundary check on num_scid is performed. When the function branches to the error handling path, rsp_len still contains the attacker-influenced value rather than being reset to a safe value.
The fix addresses this by relocating the rsp_len assignment to occur after the num_scid boundary validation. In the corrected implementation, if the packet is rejected due to excessive SCIDs, rsp_len safely remains at 0, and the error response only reads the 8-byte base header from the stack.
Attack Vector
The attack can be performed by any Bluetooth-capable device within radio range of the target system. The attacker crafts a malicious L2CAP Enhanced Credit Based Connection Request packet containing more than 5 SCIDs in the payload.
When the target kernel processes this packet, the vulnerable code path is triggered. The attack requires no authentication and exploits the L2CAP signaling channel, which is accessible before pairing or bonding is established.
The vulnerability mechanism involves sending an oversized SCID array that bypasses initial length validation, causing the kernel to read beyond allocated stack memory when constructing the response. For detailed technical implementation, refer to the kernel commit patches.
Detection Methods for CVE-2026-31513
Indicators of Compromise
- KASAN kernel panics or warnings referencing l2cap_build_cmd() or l2cap_ecred_conn_req()
- Kernel log entries indicating stack-out-of-bounds read in Bluetooth subsystem
- Unexpected system crashes during Bluetooth operations
- Suspicious L2CAP connection attempts with abnormally large SCID counts
Detection Strategies
- Enable KASAN (Kernel Address Sanitizer) in kernel configuration to detect memory access violations
- Monitor kernel logs for Bluetooth L2CAP-related stack corruption warnings
- Implement Bluetooth traffic monitoring to identify malformed L2CAP signaling packets
- Deploy endpoint detection solutions capable of identifying kernel exploitation attempts
Monitoring Recommendations
- Configure system logging to capture kernel Bluetooth subsystem messages at debug level
- Implement alerting on KASAN panic events in production systems
- Monitor for unusual Bluetooth connection patterns or repeated connection request failures
- Review kernel crash dumps for evidence of L2CAP-related memory corruption
How to Mitigate CVE-2026-31513
Immediate Actions Required
- Update the Linux kernel to a patched version containing the fix
- If immediate patching is not possible, consider disabling Bluetooth functionality on critical systems
- Monitor systems for signs of exploitation attempts
- Review Bluetooth device pairing policies and limit exposure to untrusted devices
Patch Information
The vulnerability has been addressed in multiple kernel commits. Apply the appropriate patch for your kernel version:
- Commit 5b35f8211a913cfe7ab9d54fa36a272d2059a588 - View Patch
- Commit 9d87cb22195b2c67405f5485d525190747ad5493 - View Patch
- Commit a3d9c50d69785ae02e153f000da1b5fd6dbfdf1b - View Patch
- Commit c8e1a27edb8b4e5afb56b384acd7b6c2dec1b7cc - View Patch
Workarounds
- Disable Bluetooth at the kernel level by blacklisting the bluetooth module
- Use rfkill to disable Bluetooth hardware when not required
- Implement network segmentation to limit Bluetooth exposure in sensitive environments
- Apply firewall rules or Bluetooth filtering where supported to block untrusted connections
# Configuration example
# Disable Bluetooth module loading
echo "blacklist bluetooth" >> /etc/modprobe.d/bluetooth-blacklist.conf
echo "blacklist btusb" >> /etc/modprobe.d/bluetooth-blacklist.conf
# Disable Bluetooth using rfkill
rfkill block bluetooth
# Verify Bluetooth is disabled
rfkill list bluetooth
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
