Bug 2454839 (CVE-2026-31393)

Summary: CVE-2026-31393 kernel: Bluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedKeywords: Security
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in the Linux kernel's Bluetooth L2CAP (Logical Link Control and Adaptation Protocol) component. A remote attacker could send a specially crafted, truncated L2CAP information response (L2CAP_INFO_RSP) packet. This insufficient validation of the payload length before accessing data leads to an out-of-bounds read of adjacent kernel memory. This could result in information disclosure or potentially a denial of service (DoS).
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-04-03 16:03:35 UTC 
In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access

l2cap_information_rsp() checks that cmd_len covers the fixed
l2cap_info_rsp header (type + result, 4 bytes) but then reads
rsp->data without verifying that the payload is present:

 - L2CAP_IT_FEAT_MASK calls get_unaligned_le32(rsp->data), which reads
   4 bytes past the header (needs cmd_len >= 8).

 - L2CAP_IT_FIXED_CHAN reads rsp->data[0], 1 byte past the header
   (needs cmd_len >= 5).

A truncated L2CAP_INFO_RSP with result == L2CAP_IR_SUCCESS triggers an
out-of-bounds read of adjacent skb data.

Guard each data access with the required payload length check.  If the
payload is too short, skip the read and let the state machine complete
with safe defaults (feat_mask and remote_fixed_chan remain zero from
kzalloc), so the info timer cleanup and l2cap_conn_start() still run
and the connection is not stalled.
Comment 1 Jon Moroney 2026-04-03 18:12:45 UTC 
Upstream advisory:
https://lore.kernel.org/linux-cve-announce/2026040325-CVE-2026-31393-5e12@gregkh/T