CVE-2020-12351: Linux Kernel BlueZ Privilege Escalation

CVE-2020-12351 Overview

CVE-2020-12351 is an improper input validation flaw in BlueZ, the official Linux Bluetooth protocol stack. The vulnerability resides in the Logical Link Control and Adaptation Protocol (L2CAP) handling within the Linux kernel and allows an unauthenticated attacker within Bluetooth radio range to trigger memory corruption. Successful exploitation can lead to escalation of privilege and remote code execution at the kernel level. The issue, publicly tracked as part of the BleedingTooth family of Bluetooth vulnerabilities, affects Linux kernel versions up to and including 5.9.1. The weakness is categorized under [CWE-20].

Critical Impact
An adjacent attacker who knows a target device's Bluetooth MAC address can send a crafted L2CAP packet to execute arbitrary code in kernel context without user interaction.

Affected Products

Linux kernel versions prior to the BlueZ fix, including the 5.9.x branch
Linux kernel 5.9.0 (including release candidates rc1 through rc6)
Linux kernel 5.9.1

Discovery Timeline

2020-11-23 - CVE-2020-12351 published to NVD
2024-11-21 - Last updated in NVD database

Technical Details for CVE-2020-12351

Vulnerability Analysis

The vulnerability resides in the L2CAP component of the Linux kernel's BlueZ Bluetooth stack. BlueZ fails to properly validate the type of an incoming L2CAP packet before processing it. An attacker within Bluetooth range can transmit a malformed packet that the kernel parses as if it were a different, attacker-chosen object type. This type confusion condition corrupts kernel memory and provides primitives for arbitrary code execution. Because Bluetooth packet handling occurs in kernel context, successful exploitation yields full kernel privileges. The attack does not require pairing, authentication, or user interaction on the target system.

Root Cause

The root cause is improper input validation [CWE-20] on the chan->data_type field of incoming L2CAP traffic. The kernel's l2cap_sock_recvmsg and related handlers assume an incoming packet structure without enforcing strict type checks. An adjacent attacker can craft packets that violate this assumption, leading to confusion between socket data types and ultimately to memory corruption inside the Bluetooth subsystem.

Attack Vector

Exploitation requires adjacent network access, meaning the attacker must be within Bluetooth radio range of the target. The attacker must know or discover the victim's Bluetooth device address (BD_ADDR), which can be enumerated from probe traffic or by sniffing nearby radios. Once the address is known, the attacker transmits crafted L2CAP packets directly to the target. No prior pairing is required. The vulnerability mechanism is described in detail in the Packet Storm BleedingTooth exploit submission and the Intel Security Advisory SA-00435.

Detection Methods for CVE-2020-12351

Indicators of Compromise

Unexpected kernel oops or panics referencing l2cap_sock_recvmsg, l2cap_chan, or net/bluetooth/ modules in dmesg and /var/log/kern.log
Bluetooth daemon (bluetoothd) restarts or crashes without legitimate user action
Inbound L2CAP traffic from unpaired Bluetooth devices on systems that do not use Bluetooth services
New kernel modules, processes, or persistence mechanisms appearing shortly after Bluetooth subsystem instability

Detection Strategies

Monitor kernel logs for crashes or warnings originating in net/bluetooth/l2cap_core.c and related source files
Audit running kernel versions across the fleet and flag hosts running vulnerable 5.9.x builds with Bluetooth enabled
Correlate endpoint telemetry for post-exploitation activity, including new root processes spawning from kernel worker contexts

Monitoring Recommendations

Inventory which Linux endpoints have the bluetooth kernel module loaded using lsmod | grep bluetooth
Alert on changes to the state of bluetoothd and on unauthorized loading of Bluetooth kernel modules
Enable kernel auditing (auditd) for syscalls related to socket creation on the AF_BLUETOOTH family

How to Mitigate CVE-2020-12351

Immediate Actions Required

Update the Linux kernel to a patched release that includes the BlueZ L2CAP type validation fix from your distribution's security advisories
Disable the Bluetooth stack on servers and endpoints that do not require it by unloading and blacklisting the bluetooth kernel module
Restrict physical proximity exposure for high-value systems by disabling Bluetooth radios in firmware where supported

Patch Information

The upstream fix was merged into the Linux kernel Bluetooth subsystem and backported by major Linux distributions. Apply vendor-supplied kernel updates referenced in the Intel Security Advisory SA-00435 and corresponding distribution advisories from Red Hat, Debian, Ubuntu, and SUSE. Reboot affected systems after applying the kernel update to load the corrected module.

Workarounds

Stop and mask the Bluetooth service: systemctl stop bluetooth && systemctl mask bluetooth
Blacklist Bluetooth kernel modules by adding blacklist bluetooth and blacklist btusb to /etc/modprobe.d/blacklist-bluetooth.conf
Physically disable Bluetooth adapters via BIOS/UEFI settings on systems where the capability is not required

bash

# Disable and blacklist the Bluetooth stack until patches are applied
sudo systemctl stop bluetooth
sudo systemctl disable bluetooth
sudo systemctl mask bluetooth

echo "blacklist bluetooth" | sudo tee /etc/modprobe.d/blacklist-bluetooth.conf
echo "blacklist btusb" | sudo tee -a /etc/modprobe.d/blacklist-bluetooth.conf

sudo rmmod btusb bluetooth 2>/dev/null