CVE-2026-45835

What it actually does

This is a Linux kernel Bluetooth L2CAP flaw that can trigger a NULL pointer dereference in l2cap_sock_new_connection_cb(). A local low-privileged user able to exercise the Bluetooth L2CAP socket path may cause the kernel to dereference an uninitialized or missing object during new connection handling. The expected impact is denial of service through a kernel oops, panic, crash, or forced reboot depending on kernel configuration. The issue does not provide known confidentiality or integrity impact and there is no indication of public exploit maturity or active exploitation.

Why it matters to the business

Successful exploitation can interrupt systems that have the affected Linux kernel Bluetooth stack enabled, causing outages, device instability, reboots, or loss of availability for workloads running on those systems. The risk is highest on laptops, desktops, edge devices, kiosks, industrial gateways, embedded Linux systems, and servers where Bluetooth is enabled or where untrusted local users can run code. EPSS is currently very low and the issue is not listed in CISA KEV, so it should be handled as a reliability and local denial-of-service patching priority rather than an emergency internet-facing compromise scenario.

How an attack unfolds

An attacker first obtains the ability to run code locally with low privileges on a system using an affected Linux kernel with Bluetooth/L2CAP functionality available. The attacker then interacts with the Bluetooth socket/L2CAP connection handling path in a way that reaches the vulnerable new-connection callback. Because the vulnerable code path lacks a NULL guard that exists in related callbacks, the kernel may attempt to dereference a NULL pointer. This results in a kernel oops or panic, which can terminate the Bluetooth subsystem, destabilize the host, or reboot the system if panic-on-oops or similar hardening/recovery settings are enabled. There is no evidence from the supplied data that this flaw enables privilege escalation, data theft, or remote unauthenticated compromise.

How to fix it

Apply a Linux kernel update from the operating system or distribution vendor that includes the upstream fix adding a NULL guard in l2cap_sock_new_connection_cb(). Because no exact fixed package versions were provided, use the latest supported kernel release for each affected distribution and verify the vendor advisory explicitly references this fix or CVE. If immediate patching is not possible, reduce exposure by disabling Bluetooth where it is not operationally required, unloading or blacklisting Bluetooth-related kernel modules where feasible, restricting local shell access to trusted users, and applying standard endpoint controls that prevent untrusted local code execution. On systems where Bluetooth is required, prioritize patching over mitigation because functional workarounds may be incomplete.

How to confirm the fix worked

Confirm that each system is running a vendor kernel build that includes the fix for the Bluetooth L2CAP NULL pointer dereference in l2cap_sock_new_connection_cb(). Validate with package manager metadata, distribution security advisories, kernel changelogs, or source/backport notes rather than relying only on the upstream kernel version string, because distributions often backport fixes. Check whether Bluetooth is enabled by reviewing loaded modules and service state, such as bluetooth, btusb, bnep, rfcomm, and l2cap-related functionality. After patching, reboot into the updated kernel and verify with uname and the package manager that the running kernel matches the installed fixed kernel. For mitigation validation, confirm Bluetooth services are disabled and relevant modules cannot be loaded if Bluetooth is not required.

Typical attack path

1. Gain local low-privileged code execution on a Linux system running an affected kernel.
2. Confirm Bluetooth/L2CAP support is present and accessible, or that relevant kernel modules are loaded.
3. Trigger the vulnerable L2CAP new-connection handling path through local Bluetooth socket interactions or a crafted local test program.
4. Cause l2cap_sock_new_connection_cb() to process a state where the expected object is NULL.
5. Induce a kernel NULL pointer dereference, resulting in an oops, panic, crash, or reboot.
6. Repeat the trigger as needed to create recurring denial of service until the kernel is patched or Bluetooth is disabled.

How to detect it

Review kernel and system logs for evidence of prior kernel oops, panic, or crash events involving the Bluetooth L2CAP stack. Useful sources include journalctl -k output, /var/log/kern.log, /var/log/messages, /var/log/syslog, persistent pstore/ramoops records, crash dumps, kdump/vmcore artifacts, endpoint telemetry, and availability monitoring that records unexpected reboots. Search for NULL pointer dereference messages, call traces containing l2cap_sock_new_connection_cb(), L2CAP/Bluetooth stack functions, and repeated crashes shortly after Bluetooth activity. Correlate suspected events with local login/session records, process execution telemetry, Bluetooth service logs, and kernel module load events to determine whether a local user or process may have intentionally triggered the path. Because the vulnerability primarily causes denial of service, forensic evidence may be limited to crash logs and reboot timelines rather than durable files or network indicators.

• l2cap_sock_new_connection_cb
• BUG: kernel NULL pointer dereference
• Oops: 0000
• kernel NULL pointer dereference
• Bluetooth: L2CAP
• Call Trace:
• l2cap_sock_resume_cb
• l2cap_sock_ready_cb
• bluetooth
• btusb
• bnep
• rfcomm
• /sys/fs/pstore
• /var/crash
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog

What your security team should do

• Inventory Linux systems with Bluetooth hardware, Bluetooth services enabled, or Bluetooth kernel modules loaded; prioritize endpoints, edge devices, and multi-user systems.
• Patch affected systems to the latest supported vendor kernel that includes the L2CAP NULL pointer dereference fix, then reboot to ensure the fixed kernel is active.
• If patching is delayed, disable Bluetooth services and block loading of Bluetooth modules on systems where Bluetooth is not required.
• Restrict local interactive access and untrusted code execution on systems that cannot be patched quickly.
• Monitor kernel logs for NULL pointer dereferences, oops, panic events, and call traces referencing l2cap_sock_new_connection_cb or Bluetooth L2CAP.
• Treat repeated crashes with Bluetooth/L2CAP call traces as potential exploitation or reliability abuse and preserve logs before reboot cycles overwrite evidence.
• Because this issue is not KEV-listed, has no known exploit maturity, and has very low EPSS, schedule remediation based on availability criticality while still addressing exposed or multi-user systems promptly.