CVE-2026-31393: Linux Kernel Buffer Overflow Vulnerability

CVE-2026-31393 Overview

A vulnerability has been discovered in the Linux kernel's Bluetooth L2CAP (Logical Link Control and Adaptation Protocol) implementation. The l2cap_information_rsp() function fails to properly validate the payload length of L2CAP_INFO_RSP packets before accessing the response data. While the function checks that cmd_len covers the fixed l2cap_info_rsp header (type + result, 4 bytes), it subsequently reads rsp->data without verifying that the payload is actually present, leading to an out-of-bounds read vulnerability.

Critical Impact

A truncated L2CAP_INFO_RSP packet with result == L2CAP_IR_SUCCESS can trigger an out-of-bounds read of adjacent skb data, potentially exposing kernel memory contents to an attacker within Bluetooth range.

Affected Products

• Linux Kernel (Bluetooth L2CAP subsystem)
• Systems with Bluetooth enabled and L2CAP functionality

Discovery Timeline

• 2026-04-03 - CVE CVE-2026-31393 published to NVD
• 2026-04-07 - Last updated in NVD database

Technical Details for CVE-2026-31393

Vulnerability Analysis

The vulnerability exists in the L2CAP information response handling code within the Linux kernel's Bluetooth stack. The l2cap_information_rsp() function processes incoming L2CAP information response packets and verifies that the command length covers the fixed header structure. However, the function proceeds to read data fields beyond this header without additional length validation.

Two specific code paths are affected:

1. L2CAP_IT_FEAT_MASK handling: The function calls get_unaligned_le32(rsp->data), which reads 4 bytes past the header. This operation requires cmd_len >= 8 bytes to be safe, but this constraint is not enforced.

2. L2CAP_IT_FIXED_CHAN handling: The function reads rsp->data[0], which is 1 byte past the header. This requires cmd_len >= 5 bytes, which is also not validated.

When a maliciously crafted or truncated L2CAP_INFO_RSP packet arrives with result == L2CAP_IR_SUCCESS but insufficient payload data, the kernel reads beyond the allocated buffer boundaries into adjacent socket buffer (skb) data.

Root Cause

The root cause is insufficient input validation in the l2cap_information_rsp() function. The function validates only the minimum header length (4 bytes) but fails to validate the presence of variable-length payload data before accessing it. This is a classic example of an input validation error where boundary conditions are not properly enforced.

Attack Vector

The vulnerability can be exploited by an attacker within Bluetooth range who can send crafted L2CAP information response packets to a target system. The attack requires:

1. Establishing a Bluetooth connection with the target device
2. Sending a truncated L2CAP_INFO_RSP packet with a successful result code but insufficient payload length
3. The target kernel reads beyond buffer boundaries, potentially leaking kernel memory contents

The fix implements proper payload length checks for each data access path. If the payload is too short, the code skips the read operation and allows the state machine to complete with safe defaults (feat_mask and remote_fixed_chan remain zero from kzalloc), ensuring the info timer cleanup and l2cap_conn_start() still run without stalling the connection.

Detection Methods for CVE-2026-31393

Indicators of Compromise

• Unusual Bluetooth traffic patterns with malformed L2CAP packets
• Kernel crash logs or memory corruption errors related to the Bluetooth subsystem
• System instability when Bluetooth devices attempt to connect

Detection Strategies

• Monitor kernel logs for out-of-bounds read warnings in the Bluetooth L2CAP subsystem
• Deploy kernel address sanitizer (KASAN) on development/test systems to detect memory access violations
• Implement Bluetooth traffic analysis to identify malformed L2CAP_INFO_RSP packets with truncated payloads

Monitoring Recommendations

• Enable kernel memory debugging features such as KASAN in non-production environments to catch exploitation attempts
• Configure audit logging for Bluetooth connection events and failures
• Monitor for unusual Bluetooth pairing requests from unknown devices

How to Mitigate CVE-2026-31393

Immediate Actions Required

• Apply the latest kernel security patches from your distribution vendor
• Consider disabling Bluetooth functionality on systems where it is not required
• Limit Bluetooth discoverability and pairing to trusted devices only

Patch Information

The Linux kernel maintainers have released patches to address this vulnerability. The fix adds proper payload length validation before each data access in l2cap_information_rsp(). Multiple kernel patch commits are available:

• Kernel Patch 3b64651
• Kernel Patch 807bd12
• Kernel Patch 9aeacd
• Kernel Patch db2872d
• Kernel Patch dd815e6
• Kernel Patch e7ff754

Workarounds

• Disable Bluetooth at the kernel level by adding bluetooth.disable_ertm=1 to kernel boot parameters
• Unload the Bluetooth kernel modules if Bluetooth functionality is not required: modprobe -r bluetooth btusb
• Use firewall rules to restrict Bluetooth connections to known, trusted devices only

# Disable Bluetooth service
sudo systemctl stop bluetooth
sudo systemctl disable bluetooth

# Unload Bluetooth kernel modules
sudo modprobe -r btusb
sudo modprobe -r bluetooth

# Blacklist Bluetooth modules to prevent loading on boot
echo "blacklist bluetooth" | sudo tee /etc/modprobe.d/disable-bluetooth.conf
echo "blacklist btusb" | sudo tee -a /etc/modprobe.d/disable-bluetooth.conf