Raw vector
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:HSummary
CVE-2026-31513 is a high-severity Out-of-bounds Read (CWE-125) vulnerability in Linux Linux Kernel. Its CVSS base score is 8.1 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploitation for Privilege Escalation (T1068); ranked at the 17th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SA-8 (Security and Privacy Engineering Principles) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-31513 is a stack out-of-bounds read vulnerability in the Linux kernel's Bluetooth L2CAP implementation, specifically within the l2cap_ecred_conn_req() function. The flaw occurs when processing a malformed Enhanced Credit Based Connection Request with more than five Source Channel IDs (SCIDs). The function allocates an 18-byte stack buffer to hold up to five SCIDs, but it calculates the response length (rsp_len) using the attacker's unvalidated cmd_len before verifying if the SCID count exceeds L2CAP_ECRED_MAX_CID. If the count is invalid, the function rejects the packet but retains the oversized rsp_len value, causing l2cap_send_cmd() to read past the end of the pdu buffer and trigger a KASAN panic.
An attacker with adjacent network access via Bluetooth, requiring no privileges or user interaction, can exploit this by sending a crafted L2CAP Enhanced Credit Based Connection Request. Successful exploitation leads to a stack out-of-bounds read, enabling potential disclosure of sensitive stack memory and kernel panic for denial-of-service. The vulnerability scores 8.1 on CVSS 3.1 (AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H) and is associated with CWE-125 (Out-of-bounds Read).
Patches for stable Linux kernel releases address the issue by moving the rsp_len assignment after the num_scid boundary check, as detailed in commits such as 5b35f8211a913cfe7ab9d54fa36a272d2059a588, 9d87cb22195b2c67405f5485d525190747ad5493, a3d9c50d69785ae02e153f000da1b5fd6dbfdf1b, and c8e1a27edb8b4e5afb56b384acd7b6c2dec1b7cc. With the reordered check, rejected packets leave rsp_len at 0, limiting reads to the safe 8-byte base header and preventing the out-of-bounds access.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-24897
Vulnerability Data
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix stack-out-of-bounds read in l2cap_ecred_conn_req Syzbot reported a KASAN stack-out-of-bounds read in l2cap_build_cmd() that is triggered by a malformed Enhanced Credit Based Connection Request. The vulnerability stems from…
more
l2cap_ecred_conn_req(). The function allocates a local stack buffer (`pdu`) designed to hold a maximum of 5 Source Channel IDs (SCIDs), totaling 18 bytes. When an attacker sends a request with more than 5 SCIDs, the function calculates `rsp_len` based on this unvalidated `cmd_len` before checking if the number of SCIDs exceeds L2CAP_ECRED_MAX_CID. If the SCID count is too high, the function correctly jumps to the `response` label to reject the packet, but `rsp_len` retains the attacker's oversized value. Consequently, l2cap_send_cmd() is instructed to read past the end of the 18-byte `pdu` buffer, triggering a KASAN panic. Fix this by moving the assignment of `rsp_len` to after the `num_scid` boundary check. If the packet is rejected, `rsp_len` will safely remain 0, and the error response will only read the 8-byte base header from the stack.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation directly finds out-of-bounds read flaws through static analysis, fuzzing, and dynamic bounds checks.
Secure engineering principles require bounds checking and memory-safe constructs that stop out-of-bounds reads from being introduced.
Process isolation confines the effects of an out-of-bounds read to the compromised process.
Input validation rejects malformed indices or lengths that would otherwise cause reads outside buffer bounds.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure-development practices such as bounds checking and memory-safe languages directly prevent out-of-bounds reads.
Vulnerability scanning and recording can discover instances of out-of-bounds reads after code is deployed.
Routine patching replaces vulnerable code containing out-of-bounds read flaws.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing in development and acceptance includes fuzzing and static analysis that detect out-of-bounds read defects before release.
Logging can record evidence of an out-of-bounds read but does not prevent the weakness itself.
Secure development life cycle mandates input validation and bounds checking that directly prevent out-of-bounds reads.
Application security requirements include explicit bounds and memory-safety specifications that mitigate buffer over-reads.
Secure system architecture and engineering principles require memory-safe design patterns and runtime protections against out-of-bounds access.
Secure coding standards explicitly forbid unsafe pointer arithmetic and mandate bounds-checked reads, eliminating CWE-125.