Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2022-42895

CVE-2022-42895: Linux Kernel Information Disclosure Flaw

CVE-2022-42895 is an information disclosure flaw in the Linux Kernel's Bluetooth L2CAP component that allows remote attackers to leak kernel pointers. This article covers the technical details, affected systems, and mitigation.

Updated:

CVE-2022-42895 Overview

CVE-2022-42895 is an information disclosure vulnerability in the Linux kernel's Bluetooth Logical Link Control and Adaptation Protocol (L2CAP) implementation. The flaw resides in the l2cap_parse_conf_req function within net/bluetooth/l2cap_core.c. An adjacent attacker within Bluetooth range can exploit uninitialized stack memory access to remotely leak kernel pointers. These leaked pointers can defeat Kernel Address Space Layout Randomization (KASLR) and enable reliable exploitation of additional kernel vulnerabilities. The issue is classified under [CWE-824] (Access of Uninitialized Pointer).

Critical Impact

Adjacent Bluetooth-range attackers can leak kernel memory pointers from vulnerable Linux systems without authentication or user interaction, providing a primitive for bypassing KASLR.

Affected Products

  • Linux Kernel (versions prior to commit b1a2cd50c0357f243b7435a732b4e62ba3157a2e)
  • Linux distributions shipping the affected net/bluetooth/l2cap_core.c implementation
  • Systems with Bluetooth enabled and reachable from adjacent attackers

Discovery Timeline

  • 2022-11-23 - CVE-2022-42895 published to NVD
  • 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2022-42895

Vulnerability Analysis

The vulnerability exists in l2cap_parse_conf_req, which processes L2CAP configuration request packets during Bluetooth connection setup. The function builds a response containing Extended Flow Specification (EFS) data drawn from a local struct l2cap_conf_efs variable. When a peer sends a configuration request that does not include an EFS option, the local efs structure remains uninitialized. The kernel still copies fields from this stack-allocated structure into the outgoing response when the FLAG_EFS_ENABLE channel flag is set, exposing residual stack contents to the remote peer.

The leaked data can include kernel pointers and other sensitive memory contents adjacent to the uninitialized buffer. Attackers can use these primitives to defeat KASLR and chain additional kernel exploits.

Root Cause

The root cause is a missing precondition check before consuming the efs structure. The original code branched on FLAG_EFS_ENABLE alone without verifying whether the remote peer actually negotiated EFS. Without a paired remote_efs check, the structure was read while its members held indeterminate stack data.

Attack Vector

Exploitation requires Bluetooth radio proximity to the target. An attacker pairs or attempts to associate with the victim and issues a crafted L2CAP configuration request that omits the EFS option while triggering the EFS-enabled response path. The kernel returns a configuration response populated with uninitialized stack bytes, which the attacker captures over the air.

c
// Patch: net/bluetooth/l2cap_core.c
// Bluetooth: L2CAP: Fix attempting to access uninitialized memory
 			l2cap_add_conf_opt(&ptr, L2CAP_CONF_RFC,
 					   sizeof(rfc), (unsigned long) &rfc, endptr - ptr);
 
-			if (test_bit(FLAG_EFS_ENABLE, &chan->flags)) {
+			if (remote_efs &&
+			    test_bit(FLAG_EFS_ENABLE, &chan->flags)) {
 				chan->remote_id = efs.id;
 				chan->remote_stype = efs.stype;
 				chan->remote_msdu = le16_to_cpu(efs.msdu);

Source: GitHub Linux Commit b1a2cd5. The fix adds a remote_efs guard ensuring the kernel only consumes the efs structure when the peer actually supplied an EFS option.

Detection Methods for CVE-2022-42895

Indicators of Compromise

  • Unsolicited or anomalous L2CAP configuration request frames originating from nearby Bluetooth devices targeting hosts with Bluetooth enabled.
  • Bluetooth association attempts from unknown peers immediately followed by configuration request exchanges that complete without establishing a useful service.
  • Kernel bluetoothd or hci0 interface activity from unfamiliar Bluetooth MAC addresses appearing in dmesg or journalctl logs.

Detection Strategies

  • Audit running kernel versions across Linux fleets and flag hosts that have not received the b1a2cd50c0357f243b7435a732b4e62ba3157a2e backport.
  • Monitor for hosts loading the bluetooth and l2cap kernel modules in environments where Bluetooth is not required for operations.
  • Capture HCI traces on at-risk hosts and inspect L2CAP Configuration Request and Configuration Response exchanges for malformed or repeated patterns.

Monitoring Recommendations

  • Forward kernel and Bluetooth subsystem logs to a central SIEM for correlation against asset inventory and patch status.
  • Track Bluetooth pairing and connection events on servers, kiosks, and workstations where Bluetooth should not normally be active.
  • Establish baselines for expected Bluetooth peer MAC addresses and alert on first-seen devices interacting with corporate endpoints.

How to Mitigate CVE-2022-42895

Immediate Actions Required

  • Upgrade the Linux kernel to a version containing commit b1a2cd50c0357f243b7435a732b4e62ba3157a2e or apply the distribution's backported patch.
  • Disable Bluetooth on systems that do not require it by unloading the bluetooth and btusb kernel modules and blacklisting them at boot.
  • Restrict Bluetooth discoverability and pairing on hosts where the radio must remain enabled, limiting exposure to adjacent attackers.

Patch Information

The upstream fix is available at the GitHub Linux Commit and tracked at the Kernel Dance Reference. The patch adds a remote_efs precondition that prevents reading the uninitialized struct l2cap_conf_efs when the peer has not negotiated Extended Flow Specification. Major Linux distributions have shipped corresponding stable kernel updates; verify your vendor's advisory for the specific package version.

Workarounds

  • Blacklist the bluetooth kernel module via /etc/modprobe.d/ to prevent the vulnerable code path from loading.
  • Stop and disable the bluetooth.service systemd unit on servers and workstations that do not require wireless audio or peripherals.
  • Physically disable Bluetooth radios in BIOS/UEFI on endpoints that have no operational need for the protocol.
bash
# Disable and blacklist the Bluetooth stack on Linux hosts
sudo systemctl stop bluetooth.service
sudo systemctl disable bluetooth.service

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

sudo rmmod btusb bluetooth 2>/dev/null || true
sudo update-initramfs -u

# Verify the kernel includes the fix commit
uname -r

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.