CVE-2026-31510

What it actually does

This vulnerability is a NULL pointer dereference in the Linux kernel Bluetooth L2CAP implementation, specifically in the l2cap_sock_ready_cb path. Under certain L2CAP connection or timeout handling conditions, the kernel may attempt to use a socket pointer before confirming it is valid. A local, low-privileged attacker who can exercise the affected Bluetooth/L2CAP code path may be able to trigger a kernel fault and cause a system crash or kernel panic. The primary impact is availability loss; the available information does not indicate confidentiality or integrity compromise, privilege escalation, or remote code execution.

Why it matters to the business

Successful exploitation can crash affected Linux systems, causing service interruption, workload disruption, device downtime, and potential loss of in-memory state. Systems that expose or rely on Bluetooth functionality, embedded Linux devices, laptops, kiosks, edge devices, and infrastructure where unprivileged local users or containers can access Bluetooth-related kernel interfaces are more relevant exposure points. The vulnerability is not listed in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS, and has no reported public exploit maturity, so remediation should be handled through normal kernel update cycles unless the system has high availability requirements or broad local user access.

How an attack unfolds

An attacker first needs local execution capability on an affected Linux system or another permitted way to exercise the vulnerable Bluetooth L2CAP kernel path. They then create or manipulate Bluetooth L2CAP activity so that connection handling, readiness callbacks, or timeout processing reaches l2cap_sock_ready_cb with an unexpected NULL socket pointer. Because the vulnerable kernel path dereferences the pointer without checking it, the kernel raises a fault. On systems configured to panic on fatal kernel exceptions, this results in a kernel panic and immediate denial of service. Even where the system does not fully panic, the affected Bluetooth subsystem or kernel worker may become unstable, and service availability can be degraded.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the Bluetooth L2CAP l2cap_sock_ready_cb NULL pointer check. Because no exact fixed package versions were provided, track the relevant distribution advisories for the installed kernel branch and install the vendor-supplied patched kernel when available. After updating, reboot into the patched kernel and remove or de-prioritize older vulnerable kernels where operationally feasible. If immediate patching is not possible, reduce exposure by disabling Bluetooth where it is not required, blocking untrusted local users from accessing Bluetooth interfaces, restricting container/device passthrough access to Bluetooth devices, and applying least privilege controls for users and services that can create Bluetooth sockets. For high-availability systems, consider temporarily unloading or blacklisting Bluetooth-related kernel modules if Bluetooth is not business-critical, after testing for operational impact.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor build that includes the Bluetooth L2CAP NULL pointer dereference fix; do not rely only on package installation status because the system must be rebooted into the patched kernel. Validate with commands such as uname -r, package manager kernel inventory, and vendor advisory mapping for the active kernel version. Confirm Bluetooth is disabled or restricted where used as a mitigation by checking service state, module loading, device access, and container/device passthrough configuration. Review kernel logs after patching or mitigation to ensure there are no recurring l2cap_sock_ready_cb, l2cap_info_timeout, KASAN null-ptr-deref, kernel oops, or panic messages. In test environments, regression testing should include normal Bluetooth pairing, L2CAP communication, and suspend/resume or timeout scenarios to confirm Bluetooth functionality remains stable.

Typical attack path

1. Obtain local, low-privileged access to an affected Linux system.
2. Confirm Bluetooth support or access to Bluetooth/L2CAP-related kernel interfaces is available.
3. Initiate crafted or abnormal L2CAP socket or connection activity that reaches the affected callback path.
4. Trigger the L2CAP timeout or connection-start handling path where l2cap_sock_ready_cb is invoked with a NULL socket pointer.
5. Cause a kernel NULL pointer dereference, leading to an oops, fatal exception, or kernel panic.
6. Use the resulting crash to disrupt workloads, force reboot, or degrade system availability.

How to detect it

Look for evidence of prior crashes or kernel faults in kernel logs, persistent journal data, crash dumps, and system reboot records. Relevant sources include dmesg output, /var/log/kern.log, /var/log/messages, /var/log/syslog, systemd journal entries from the kernel facility, pstore records, kdump/vmcore artifacts, and endpoint telemetry that records kernel panics or unexpected reboots. Search for Bluetooth L2CAP function names and NULL pointer dereference signatures, especially l2cap_sock_ready_cb, l2cap_conn_start, and l2cap_info_timeout. Correlate any crash with local user sessions, container launches, Bluetooth service activity, new processes opening Bluetooth sockets, or nearby failed Bluetooth connection attempts. Since the known impact is denial of service, indicators are primarily crash artifacts rather than persistent malware traces. Absence of these logs does not prove non-exploitation if logs are volatile, overwritten, or unavailable after reboot.

• KASAN: null-ptr-deref
• null-ptr-deref in range [0x0000000000000260-0x0000000000000267]
• l2cap_sock_ready_cb
• l2cap_conn_start
• l2cap_info_timeout
• Workqueue: events l2cap_info_timeout
• Kernel panic - not syncing: Fatal exception
• RIP: 0010:kasan_byte_accessible
• Call Trace:
• Bluetooth: L2CAP
• lock_sock_nested
• process_scheduled_works
• worker_thread
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /sys/fs/pstore
• /var/crash

What your security team should do

• Inventory Linux systems with Bluetooth hardware, Bluetooth services enabled, or Bluetooth device passthrough to containers or virtualized workloads.
• Prioritize patching systems with local multi-user access, kiosk/edge deployments, laptops, embedded devices, and availability-sensitive workloads.
• Apply vendor kernel updates that include the fix and reboot systems into the patched kernel.
• Disable Bluetooth on servers and production systems where it is not explicitly required.
• Restrict unprivileged and containerized access to Bluetooth devices and related kernel interfaces until patched.
• Monitor kernel logs for l2cap_sock_ready_cb, l2cap_info_timeout, KASAN null-ptr-deref, fatal exception, and kernel panic patterns.
• Treat unexplained kernel crashes involving Bluetooth/L2CAP as potential exploitation or reliability events and preserve logs before reboot rotation removes evidence.
• Because EPSS is very low, the issue is not in CISA KEV, and no exploitation maturity is reported, handle at standard patch priority unless business availability requirements or local-user exposure justify acceleration.