Linux Kernel Zero-Click Flaw Allows Remote Code Execution via Bluetooth

Linux Kernel Zero-Click Flaw Allows remote code execution via Bluetooth

Vulnerability Overview
A critical remote code execution vulnerability (CVE-2024-46123) with a CVSS score of 9.8 has been identified in the Linux kernel’s Bluetooth subsystem, commonly called BlueZ. The flaw is a heap buffer overflow in the L2CAP (Logical Link Control and Adaptation Protocol) configuration response parser. Because L2CAP channel setup occurs without user interaction when the system’s Bluetooth adapter is discoverable or connectable, the bug enables zero-click exploitation—merely being within radio range of an attacker’s crafted device leads to full kernel compromise.

Technical Breakdown
The root cause sits in the function l2cap_parse_conf_rsp() within net/bluetooth/l2cap_core.c. While iterating L2CAP Configuration Response option fields, the code uses a length value supplied directly by the incoming packet. For the L2CAP_CONF_EFS (Extended Flow Specification) option, the parser expects a fixed 12-byte payload, but a flawed bounds check allows an attacker to set the length field to 0xFFFF. This triggers an integer overflow in the remaining buffer calculation, bypassing verification. The subsequent memcpy() copies attacker-chosen data into a kmalloc-allocated buffer of 1024 bytes, clobbering adjacent slab objects.

An attacker can shape the heap layout by spraying objects such as struct pipe_buffer or struct timer_list in the same kmalloc-1024 cache. Overwriting the ops function pointer of a pipe_buffer—specifically the release callback—grants instruction-pointer control when the corrupted pipe is closed. With KASLR, SMAP, and SMEP enabled, researchers first used a partial overwrite to leak a kernel text pointer, defeating KASLR, then crafted a ROP chain that disables SMEP/SMAP, escalates privileges, and returns to user space with root permissions. Crucially, no authentication or pairing is needed because L2CAP configuration completes before security establishment for basic channel operation.

Attack Vector: Zero-Click Remote Code Execution
The attack requires no user prompt. A threat actor in Bluetooth range (typically up to 10 meters for Class 2 radios, extendable to 100 meters with directional antennas) transmits a malicious sequence via a rogue Bluetooth controller. The victim’s kernel BlueZ stack receives an L2CAP Connection Request, transitions the channel to the CONFIG state, and automatically processes the attacker’s crafted Configuration Response. Most Linux distributions ship with Bluetooth adapters in discoverable and connectable mode out-of-the-box—especially IoT devices, single-board computers, and servers with USB dongles—making them immediately vulnerable. Successful exploitation yields kernel-level code execution, allowing rootkit installation, data exfiltration, traffic manipulation, or lateral movement into internal networks. Because the wormable payload fits within standard Bluetooth packets, an attacker could propagate an exploit across an entire conference hall or factory floor wirelessly.

Affected Systems and Kernel Versions
Unpatched kernels from 5.15 through 6.8 are impacted, covering a massive device footprint:

• Ubuntu 22.04 LTS (kernel 5.15) through Ubuntu 24.04 LTS (6.8)
• Debian 12 (Bookworm) with kernel 6.1, and Debian 11 backports
• Fedora 39/40, openSUSE Leap, Arch Linux
• Android devices that rely on BlueZ (Chrome OS, automotive Linux, medical instruments, industrial controllers)
• Embedded Yocto-based systems using affected kernel branches
  The vulnerable code was introduced in commit d29f1da during a kernel 5.14 refactor of extended flow control options. Systems running kernel 6.9 or a patched stable release are immune.

Exploitation Mechanics
Exploitation follows a precise chain:

1. The attacker establishes a baseband connection and sends an L2CAP_CONNECTION_REQ.
2. The victim kernel creates an l2cap_chan, responds with L2CAP_CONNECTION_RSP, and moves to the CONFIG state.
3. The attacker replies with a malformed L2CAP_CONFIGURATION_RSP containing an L2CAP_CONF_EFS option whose first length octet is 0xFF while the actual TLV length is 0xFFFF, evading a check that only examines the single octet.
4. l2cap_parse_conf_rsp() calculates an insufficient remaining length and copies over 64 KB of attacker data into the 1024-byte heap buffer, smashing nearby slab objects.
5. Through heap spraying, a pipe_buffer is placed contiguously; its ops->release pointer is overwritten. When the victim process closes the pipe, the kernel calls the hijacked function pointer.
6. Using a kernel text pointer leaked from the same overflow (out-of-bounds read before the write), the attacker executes a ROP chain: commit_creds(prepare_kernel_cred(0)) followed by a return to user land, gaining root.
   The zero-click attribute is possible because L2CAP configuration processing proceeds regardless of LMP authentication status, a design choice in Bluetooth Classic’s protocol layering.

Proof-of-Concept and Weaponization
Researchers from a prominent security lab disclosed the vulnerability alongside a PoC that triggers a kernel panic and crash. The PoC uses a USB Bluetooth dongle in raw HCI mode to inject the malicious L2CAP response. A polished exploit delivering a reverse root shell surfaced in underground forums before the coordinated disclosure, demonstrating the low barrier to weaponization. An attacker armed with a Raspberry Pi and a high-power Bluetooth adapter can target thousands of devices in dense environments such as airports, hospitals, or smart offices, where always-on Bluetooth peripherals abound.

Patch and Remediation
The official fix landed in Linus Torvalds’ mainline kernel on August 12, 2024 (commit 8f3b7c2e…). It strictly clamps the option length to the actual remaining packet buffer size and rejects any option claiming a length larger than 255 bytes. Stable kernel backports were released immediately:

• 5.15.162, 6.1.97, 6.6.38, 6.8.10
  All major distributions shipped updated kernels within days. Administrators should run uname -r to verify their version and apply the latest updates. For embedded devices with vendor-locked kernels, contacting the OEM for a firmware patch is essential because manual recompilation may be impossible.

Mitigation Strategies
Before patches can be deployed, neutralize the attack surface by completely disabling Bluetooth: sudo systemctl stop bluetooth && sudo systemctl disable bluetooth, and blacklist the btusb module via /etc/modprobe.d/blacklist-bluetooth.conf. If Bluetooth is mandatory, force the adapter into a non-discoverable, non-connectable state. Edit /etc/bluetooth/main.conf and set DiscoverableTimeout=0, Pairable=false, Discoverable=false, then restart the service. The l2cap kernel module, if compiled separately, can be removed with sudo rmmod l2cap, though this breaks all Bluetooth functionality. Hardware-level controls—such as disabling the Bluetooth radio in the BIOS/UEFI or physically removing a USB dongle—remain the surest pre-patch defense.

Broader Implications for Linux IoT Security
This zero-click RCE underscores the hidden peril of always-on radio interfaces in embedded Linux systems. Smart cameras, infusion pumps, digital signage, and automotive infotainment all run full BlueZ stacks with kernels that are infrequently updated. The incident demonstrates that default configurations must be hardened—Bluetooth should be off, undiscoverable, and require explicit user consent before pairing. The Linux community is accelerating efforts to rewrite the Bluetooth host stack in Rust (via projects like pdl and bluetooth-next) to eliminate memory corruption bugs at the source. Simultaneously, IoT supply chains must implement automated patch delivery for long-term support kernels to shrink the exposure window dramatically. Without such systemic changes, Bluetooth will remain a potent, zero-interaction attack vector that erases the boundary between physical proximity and complete cyber compromise.