CVE-2026-31393

Vulnerability

Overview

In the Linux kernel's Bluetooth L2CAP implementation, the function l2cap_information_rsp() does not properly validate that the response payload length is sufficient before accessing data past the fixed header [1]. While the code correctly checks that cmd_len covers the initial 4-byte l2cap_info_rsp header (type + result), it subsequently reads variable-length payload data without verifying the actual payload length [1].

Exploitation

Vector

An attacker can send a truncated L2CAP_INFO_RSP packet where result == L2CAP_IR_SUCCESS but the packet data ends immediately after the 4-byte header [1]. When processing such a packet, the handler accesses rsp->data without checking that sufficient bytes are present. For example, L2CAP_IT_FEAT_MASK reads 4 bytes (via get_unaligned_le32) requiring at least 8 total bytes, and L2CAP_IT_FIXED_CHAN reads 1 byte requiring at least 5 total bytes [1]. This lack of validation leads to an out-of-bounds read from the adjacent socket buffer data [1].

Impact

The out-of-bounds read could expose sensitive kernel memory or cause a denial of service if the read accesses unmapped memory, though the primary concern is information disclosure [1]. No authentication is required beyond being able to send L2CAP signaling packets over a Bluetooth connection [1].

Mitigation

The fix adds explicit payload length checks before each data access [1][2][3][4]. If the payload is too short, the affected fields (feat_mask and remote_fixed_chan) are left at their zero-initialized defaults, allowing the connection state machine to proceed normally without stalling [1]. Patches have been applied to multiple stable kernel branches [1][2][3][4].