CVE-2026-45834

What it actually does

This vulnerability is a NULL pointer dereference in the Linux kernel Bluetooth L2CAP socket state-change callback, l2cap_sock_state_change_cb(). Under specific L2CAP socket lifecycle or state-transition conditions, the kernel can attempt to dereference a NULL object that should have been checked before use. The primary impact is local denial of service: a low-privileged local user may be able to trigger a kernel oops or panic, especially on systems where Bluetooth support is enabled and kernel panic behavior is configured to reboot on oops. The flaw does not directly provide confidentiality or integrity impact based on the published scoring.

Why it matters to the business

Successful exploitation can crash or destabilize affected Linux systems, causing service interruption, workload disruption, or unexpected reboot. The risk is highest for endpoints, laptops, embedded Linux devices, kiosks, industrial systems, and servers with Bluetooth enabled or exposed to local users. This issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has no reported exploit maturity, and has a low EPSS score, so broad internet-scale exploitation is unlikely; however, local denial-of-service bugs can still be operationally significant on shared systems and high-availability platforms.

How an attack unfolds

An attacker first obtains local access to an affected Linux system with sufficient privileges to interact with Bluetooth/L2CAP functionality. They then create or manipulate Bluetooth L2CAP socket activity so that the vulnerable state-change callback is reached while an expected internal pointer is NULL. Because l2cap_sock_state_change_cb() lacks the NULL guard used in related callbacks, the kernel dereferences the NULL pointer. This can produce a kernel oops, terminate affected kernel execution paths, or panic/reboot the host depending on kernel configuration. There is no indication from the provided data that the vulnerability enables remote code execution, privilege escalation, data theft, or persistent compromise by itself.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix adding a NULL guard to l2cap_sock_state_change_cb(). Because no exact fixed package versions were provided, use the fixed kernel packages from the relevant Linux distribution or vendor advisory once available. Prioritize systems where Bluetooth is enabled, where untrusted local users can execute code, and where unexpected reboot would cause operational impact. If immediate patching is not possible, reduce exposure by disabling Bluetooth where not required, blocking Bluetooth kernel module loading where operationally acceptable, restricting local shell access, limiting untrusted workloads, and reviewing kernel panic-on-oops settings for availability-sensitive systems. Potential mitigations include disabling Bluetooth services, blacklisting Bluetooth-related modules such as bluetooth, btusb, and l2cap where compatible with business needs, or enforcing endpoint policies that prevent use of Bluetooth on servers and shared systems.

How to confirm the fix worked

Confirm remediation by verifying that systems are running a vendor kernel build that includes the fix for the Bluetooth L2CAP NULL pointer dereference. Check the running kernel version with uname -a and compare it against the relevant distribution security advisory or package changelog. On source-based or custom kernels, verify that l2cap_sock_state_change_cb() contains a NULL guard equivalent to the checks present in l2cap_sock_resume_cb() and l2cap_sock_ready_cb(). Validate mitigation by confirming Bluetooth is disabled or the relevant modules are not loaded where Bluetooth is not needed, for example by checking lsmod output, system Bluetooth service state, and kernel module blacklist configuration. Review kernel logs after patching or mitigation to ensure there are no recurring NULL pointer dereferences or crashes involving L2CAP or l2cap_sock_state_change_cb().

Typical attack path

1. Gain local access to an affected Linux system, such as through an interactive user account, local shell, compromised account, or untrusted local workload.
2. Confirm that the running kernel includes the vulnerable Bluetooth L2CAP code path and that Bluetooth functionality is enabled or available.
3. Open and manipulate Bluetooth L2CAP socket state in a way that reaches the vulnerable l2cap_sock_state_change_cb() path.
4. Trigger the missing NULL-check condition during a socket state transition.
5. Cause a kernel NULL pointer dereference, resulting in a kernel oops, process disruption, system instability, or host reboot depending on kernel panic settings.

How to detect it

To determine whether this issue may have already been triggered, review kernel and system logs for Bluetooth/L2CAP-related kernel oops, NULL pointer dereference, panic, or unexpected reboot events. Relevant log sources include dmesg output, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dump records, kdump/vmcore artifacts, and endpoint telemetry that records kernel faults or reboots. Focus on entries referencing l2cap_sock_state_change_cb(), Bluetooth L2CAP, NULL pointer dereference, kernel BUG/Oops, general protection fault, or call traces involving net/bluetooth/l2cap_sock.c. Correlate any such crash with local user sessions, suspicious local process execution, Bluetooth socket activity, recent account compromise, or repeated reboot patterns. Because this is a denial-of-service issue and no public exploitation or KEV activity is indicated, absence of these crash artifacts is generally the best available evidence that exploitation has not occurred.

• l2cap_sock_state_change_cb
• Bluetooth: L2CAP
• BUG: kernel NULL pointer dereference
• kernel NULL pointer dereference
• Oops: 0000
• RIP: 0010:l2cap_sock_state_change_cb
• Call Trace:
• net/bluetooth/l2cap_sock.c
• general protection fault
• Kernel panic - not syncing
• panic_on_oops
• Bluetooth socket
• L2CAP socket
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• journalctl -k
• dmesg

What your security team should do

• Inventory Linux systems with Bluetooth enabled or Bluetooth kernel modules loaded, prioritizing endpoints, shared workstations, embedded devices, and high-availability systems.
• Apply vendor-supplied kernel updates that include the L2CAP NULL pointer dereference fix as soon as practical within normal vulnerability management timelines.
• Disable Bluetooth on servers and other systems where it is not required, and prevent automatic loading of Bluetooth-related kernel modules where operationally acceptable.
• Review local access controls and reduce opportunities for untrusted local users or workloads to interact with Bluetooth interfaces.
• Monitor kernel logs for crashes, oops messages, or call traces referencing l2cap_sock_state_change_cb, L2CAP, or Bluetooth socket state changes.
• For critical systems, review panic_on_oops and reboot-on-panic behavior so a local kernel oops does not unnecessarily create broader operational outages.
• Track distribution advisories for exact fixed package versions because fixed_versions were not provided in the input.