CVE-2026-31498: Linux Kernel Bluetooth L2CAP DOS Vulnerability

CVE-2026-31498 Overview

CVE-2026-31498 is a vulnerability in the Linux kernel's Bluetooth L2CAP (Logical Link Control and Adaptation Protocol) subsystem. The flaw affects the ERTM (Enhanced Retransmission Mode) implementation, specifically in how the kernel handles L2CAP reconfiguration requests. This vulnerability can lead to memory leaks and an infinite loop condition that exhausts system memory, potentially resulting in a denial of service condition.

The vulnerability stems from two interconnected issues: improper resource management during ERTM re-initialization and missing validation of the pdu_len parameter in packet segmentation logic. When exploited, an attacker within Bluetooth range could crash the system or cause significant resource exhaustion.

Critical Impact

This vulnerability can cause complete memory exhaustion and system denial of service through an infinite loop in the Bluetooth L2CAP subsystem when processing malformed configuration requests.

Affected Products

• Linux kernel (Bluetooth L2CAP subsystem)
• Systems with Bluetooth functionality enabled
• Devices using L2CAP ERTM mode for Bluetooth connections

Discovery Timeline

• April 22, 2026 - CVE-2026-31498 published to NVD
• April 23, 2026 - Last updated in NVD database

Technical Details for CVE-2026-31498

Vulnerability Analysis

The vulnerability exists in the l2cap_config_req() function which processes CONFIG_REQ messages for L2CAP channels that are already in the BT_CONNECTED state. This functionality is designed to support L2CAP reconfiguration operations such as MTU changes during an active connection.

During the initial channel configuration, both CONF_INPUT_DONE and CONF_OUTPUT_DONE flags are set. When a reconfiguration request arrives, the code path incorrectly falls through to l2cap_ertm_init(), which re-initializes critical data structures including tx_q, srej_q, srej_list, and retrans_list. The problem is that this re-initialization occurs without first freeing the previously allocated resources, causing a memory leak. Additionally, chan->sdu is set to NULL without freeing the existing socket buffer (skb).

The second component of this vulnerability involves the l2cap_parse_conf_req() function, which fails to validate the minimum value of remote_mps derived from the RFC max_pdu_size option. When a zero value is permitted, it propagates to l2cap_segment_sdu() where pdu_len becomes zero. This causes a while loop that iterates over the SDU (Service Data Unit) data to never terminate because the len variable is never decremented, resulting in infinite iteration and eventual memory exhaustion.

Root Cause

The root cause is twofold: first, missing cleanup logic for ERTM resources when handling channel reconfiguration in an already-connected state; second, insufficient input validation in l2cap_parse_conf_req() that allows a zero pdu_len value to reach the segmentation logic in l2cap_segment_sdu().

Attack Vector

An attacker with Bluetooth connectivity to the target system can exploit this vulnerability by:

1. Establishing a valid L2CAP connection with ERTM mode enabled
2. Sending a crafted CONFIG_REQ packet to trigger reconfiguration
3. Including a malformed RFC option with max_pdu_size set to zero

This triggers both the memory leak (through repeated ERTM re-initialization) and the infinite loop condition, leading to denial of service through memory exhaustion. The attack requires the attacker to be within Bluetooth range of the target device.

The vulnerability exists in the kernel's Bluetooth L2CAP layer where reconfiguration handling and PDU segmentation occur. The fix involves skipping l2cap_ertm_init() and l2cap_chan_ready() when the channel is already in BT_CONNECTED state, while still allowing reconfiguration parameters to be updated. Additionally, a zero-check for pdu_len was added to l2cap_segment_sdu() as a safeguard against the infinite loop condition. See the kernel git commits for technical implementation details.

Detection Methods for CVE-2026-31498

Indicators of Compromise

• Unusual memory consumption growth on systems with active Bluetooth connections
• Kernel log messages indicating L2CAP configuration requests on established channels
• System hangs or crashes associated with Bluetooth activity
• High CPU utilization in kernel Bluetooth threads

Detection Strategies

• Monitor for repeated L2CAP CONFIG_REQ packets on already-established Bluetooth channels
• Implement kernel tracing to detect l2cap_ertm_init() calls on channels in BT_CONNECTED state
• Watch for memory allocation patterns consistent with resource leak in the Bluetooth subsystem
• Deploy network-level monitoring for malformed Bluetooth L2CAP packets with zero-value RFC options

Monitoring Recommendations

• Enable kernel memory leak detection tools (kmemleak) on systems with Bluetooth functionality
• Configure system monitoring to alert on abnormal memory consumption patterns
• Implement Bluetooth traffic logging for forensic analysis capabilities
• Set up automated kernel log analysis to detect L2CAP-related anomalies

How to Mitigate CVE-2026-31498

Immediate Actions Required

• Apply the latest kernel security patches containing the fix for this vulnerability
• Disable Bluetooth functionality on systems where it is not required
• Restrict Bluetooth pairing to trusted devices only
• Monitor systems with Bluetooth enabled for signs of memory exhaustion

Patch Information

The fix has been committed to multiple stable kernel branches. The patch modifies the L2CAP reconfiguration path to skip l2cap_ertm_init() and l2cap_chan_ready() when the channel is already connected, and adds validation to prevent zero pdu_len values. Organizations should update to patched kernel versions as soon as possible.

Patch commits are available at:

• Kernel Git Commit 042e2cd
• Kernel Git Commit 25f420a
• Kernel Git Commit 52667c8
• Kernel Git Commit 900e4db

Workarounds

• Disable Bluetooth at the kernel level by blacklisting the bluetooth module if Bluetooth functionality is not required
• Implement network segmentation to limit Bluetooth exposure in sensitive environments
• Use Bluetooth management tools to restrict discoverable mode and limit pairing capabilities
• Consider disabling L2CAP ERTM mode if application requirements permit basic mode operation

# Disable Bluetooth module loading
echo "blacklist bluetooth" >> /etc/modprobe.d/blacklist-bluetooth.conf
echo "blacklist btusb" >> /etc/modprobe.d/blacklist-bluetooth.conf

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

# Verify Bluetooth is disabled
hciconfig -a