CVE-2026-43020

What it actually does

A local attacker with the ability to submit Bluetooth management commands can load a malformed Bluetooth Low Energy Long Term Key record with an encryption size larger than the kernel’s fixed 16-byte key buffer. The Linux kernel later reuses that stored value while responding to LE Long Term Key requests, causing a stack-based buffer overflow in kernel context. Successful exploitation can lead to kernel memory corruption, potentially enabling privilege escalation, arbitrary code execution in the kernel, information disclosure, or a system crash.

Why it matters to the business

Systems with Bluetooth support enabled may be exposed to local privilege escalation or denial-of-service risk if an attacker already has local code execution or access to a process/container with sufficient Bluetooth management privileges. Although there is no known public exploit, no CISA KEV listing, and EPSS is currently very low and flat, the impact is high because successful exploitation could compromise the operating system kernel and undermine host integrity.

How an attack unfolds

An attacker first obtains local execution on a Linux system where Bluetooth is enabled and the attacker can interact with the Bluetooth management interface, typically requiring elevated local privileges or delegated capabilities. The attacker submits a crafted Load Long Term Keys management request containing an invalid LTK record whose enc_size value exceeds the 16-byte key buffer size. Because vulnerable kernels store this oversized value without proper validation, the malformed key remains in kernel Bluetooth state. When an LE Long Term Key request later causes the kernel to generate a reply using that stored encryption size, the kernel performs fixed-size stack operations using the attacker-controlled oversized length, overflowing the stack buffer. Depending on kernel configuration and exploit reliability, this may crash the system or be shaped into broader kernel memory-corruption exploitation.

How to fix it

Update affected Linux kernels to a vendor or upstream kernel build that includes the fix for validating Bluetooth management LTK enc_size values during Load Long Term Keys processing. No exact fixed package versions were provided, so use distribution security advisories and kernel changelogs to identify the first fixed kernel for each platform. After installation, reboot into the updated kernel and remove older vulnerable boot entries where operationally appropriate. If immediate patching is not possible, reduce exposure by disabling Bluetooth where not required, unloading Bluetooth-related kernel modules, blocking or removing access to Bluetooth devices, and tightly restricting local privileges/capabilities such as CAP_NET_ADMIN, especially in containers and shared systems.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, is updated by checking the booted kernel version and matching it against the distribution’s advisory. Review kernel package changelogs or source patches for the fix titled or described as validating LTK enc_size on load in the Bluetooth MGMT code path. Verify that Bluetooth is disabled or unavailable on systems where it is not required. Where safe testing is possible, a malformed Bluetooth management Load Long Term Keys request with enc_size greater than 16 should be rejected rather than stored and later used. Monitor for absence of kernel oops, panic, or stack-protector events related to Bluetooth management after remediation.

Typical attack path

1. Gain local code execution on a Linux host with Bluetooth kernel support present.
2. Obtain the ability to issue Bluetooth management commands, such as through CAP_NET_ADMIN or another privileged local context.
3. Send a crafted Load Long Term Keys request containing an LTK record with enc_size greater than 16 bytes.
4. Trigger or wait for an LE Long Term Key request path that causes the malformed stored key to be used.
5. Cause a kernel stack buffer overflow during the LTK reply operation.
6. Leverage the resulting memory corruption for denial of service or potential kernel-level privilege escalation.

How to detect it

To assess possible prior exploitation, review kernel logs, system journals, crash dumps, and centralized logging for kernel oops, panic, stack-protector, or memory-corruption events involving Bluetooth, MGMT, LTK, or LE Long Term Key handling. Examine audit logs for local processes unexpectedly using Bluetooth management sockets or running with CAP_NET_ADMIN, especially shortly before a crash or reboot. Review authentication and privilege-escalation logs for new local access preceding Bluetooth-related kernel faults. On systems with crash dumping enabled, preserve vmcore artifacts and inspect backtraces for Bluetooth management functions and LTK request/reply paths. There are no known public exploit signatures or named threat actors associated with this issue at this time, so detection should focus on anomalous privileged local Bluetooth management activity and correlated kernel instability.

• MGMT_OP_LOAD_LONG_TERM_KEYS
• Load Long Term Keys
• LE Long Term Key Request
• enc_size
• Long Term Key
• Bluetooth: MGMT
• kernel: stack smashing detected
• stack-protector: Kernel stack is corrupted
• kernel BUG
• kernel NULL pointer dereference
• general protection fault
• Kernel panic - not syncing
• bluetoothd
• btusb
• bluetooth

What your security team should do

• Prioritize patching Linux systems that have Bluetooth enabled and allow local users, untrusted workloads, desktop logins, kiosk use, or container workloads with elevated network capabilities.
• Inventory systems with Bluetooth kernel modules loaded or Bluetooth hardware exposed, and disable Bluetooth on servers and production workloads where it is unnecessary.
• Restrict CAP_NET_ADMIN and other elevated capabilities from containers, service accounts, and non-administrative users unless explicitly required.
• Review kernel crash logs and audit records for suspicious Bluetooth management activity before and after patching.
• Track distribution advisories for exact fixed kernel package versions because no universal fixed version was provided.
• Treat any unexplained kernel crash involving Bluetooth management, LTK handling, or stack corruption as potentially security-relevant and preserve crash dumps for analysis.