CVE-2026-31510: Linux Kernel Bluetooth Buffer Overflow

CVE-2026-31510 Overview

A null pointer dereference vulnerability has been discovered in the Linux kernel's Bluetooth L2CAP (Logical Link Control and Adaptation Protocol) subsystem. The vulnerability exists in the l2cap_sock_ready_cb function, where the code fails to check if the socket pointer (sk) is null before using it. This can lead to a kernel panic and system crash when processing Bluetooth L2CAP connections.

The vulnerability was identified through KASAN (Kernel Address SANitizer) testing, which detected a null pointer dereference in the memory range [0x0000000000000260-0x0000000000000267]. The issue occurs during the l2cap_info_timeout workqueue processing, specifically when l2cap_conn_start triggers l2cap_sock_ready_cb with an invalid socket pointer.

Critical Impact

Local attackers can trigger a kernel panic through Bluetooth L2CAP connection handling, causing a complete system denial of service condition.

Affected Products

• Linux kernel versions with Bluetooth L2CAP support
• Systems running kernel versions prior to the security patches
• Embedded Linux systems with Bluetooth functionality enabled

Discovery Timeline

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

Technical Details for CVE-2026-31510

Vulnerability Analysis

This vulnerability is a classic null pointer dereference condition in kernel-space code. The l2cap_sock_ready_cb callback function is invoked during L2CAP connection establishment as part of the l2cap_conn_start routine. When this callback is triggered via the l2cap_info_timeout workqueue handler, the socket structure pointer may be null under certain race conditions or connection state transitions.

The kernel stack trace reveals that the crash occurs in the lock_sock_nested function when attempting to acquire a lock on the null socket pointer. The dereference happens at offset 0x260, which corresponds to a field within the socket structure that the locking code attempts to access. Since no bounds checking exists before the pointer access, the kernel immediately triggers a fatal exception.

Root Cause

The root cause of this vulnerability is missing null pointer validation in the l2cap_sock_ready_cb function. Before the fix, the code directly used the sk (socket) pointer without first verifying that it contained a valid address. This oversight allows the function to be called in contexts where the associated socket has already been freed or was never properly initialized.

The fix adds a simple null check before any operations on the socket pointer are performed, preventing the dereference of an invalid memory address.

Attack Vector

An attacker with local access to a system with Bluetooth enabled could potentially trigger this vulnerability by:

1. Initiating a Bluetooth L2CAP connection that enters a specific timing window
2. Manipulating Bluetooth connection states to create race conditions
3. Causing the l2cap_info_timeout handler to execute when the socket is in an invalid state

The attack results in a kernel panic, which crashes the entire system and causes a denial of service. While this vulnerability does not directly allow code execution or privilege escalation, it can be used to disrupt system availability.

The vulnerability is triggered through the kernel workqueue system when processing scheduled L2CAP operations. The call chain involves process_scheduled_works → l2cap_info_timeout → l2cap_conn_start → l2cap_sock_ready_cb, where the final callback attempts to lock a null socket.

Detection Methods for CVE-2026-31510

Indicators of Compromise

• Kernel panic messages containing l2cap_sock_ready_cb in the stack trace
• KASAN reports showing null pointer dereferences in the range 0x260-0x267
• System crashes during Bluetooth connection establishment or timeout handling
• Kernel logs showing workqueue crashes in l2cap_info_timeout

Detection Strategies

• Monitor kernel logs for panic traces referencing L2CAP Bluetooth subsystem functions
• Deploy KASAN-enabled debug kernels in testing environments to detect null pointer accesses
• Use kernel crash dump analysis tools to identify L2CAP-related null dereferences
• Implement Bluetooth activity monitoring to detect unusual connection patterns

Monitoring Recommendations

• Enable kernel crash dump collection to capture diagnostic information during system panics
• Configure syslog monitoring for Bluetooth subsystem errors and warnings
• Deploy endpoint detection tools that can identify kernel-level anomalies
• Monitor system availability metrics for unexpected reboots or crashes

How to Mitigate CVE-2026-31510

Immediate Actions Required

• Update the Linux kernel to a patched version containing the null pointer check fix
• Disable Bluetooth functionality on critical systems if not required
• Monitor systems for unexpected crashes related to Bluetooth operations
• Apply vendor-provided kernel updates as soon as available

Patch Information

The Linux kernel development team has released patches to address this vulnerability. The fix adds a null pointer check before using the sk pointer in l2cap_sock_ready_cb. Multiple kernel stable branches have received this fix through the following commits:

• Kernel Git Commit 03d4eaf
• Kernel Git Commit 0780f93
• Kernel Git Commit 1dc6db0
• Kernel Git Commit 3c821bc
• Kernel Git Commit 898b89c
• Kernel Git Commit a04a760
• Kernel Git Commit b6552e0
• Kernel Git Commit d34776c

Workarounds

• Disable Bluetooth at the kernel level by blacklisting Bluetooth modules: blacklist bluetooth in /etc/modprobe.d/
• Use rfkill block bluetooth to disable Bluetooth interfaces at runtime
• Remove or disable unnecessary Bluetooth services on servers and critical infrastructure
• Implement network segmentation to limit exposure of vulnerable systems

# Disable Bluetooth kernel modules
echo "blacklist bluetooth" >> /etc/modprobe.d/bluetooth-blacklist.conf
echo "blacklist btusb" >> /etc/modprobe.d/bluetooth-blacklist.conf
echo "blacklist btintel" >> /etc/modprobe.d/bluetooth-blacklist.conf

# Block Bluetooth interfaces at runtime
rfkill block bluetooth

# Verify Bluetooth is disabled
rfkill list bluetooth