CVE-2026-53253: Linux Kernel Buffer Overflow Vulnerability

CVE-2026-53253 Overview

CVE-2026-53253 is an out-of-bounds read vulnerability in the Linux kernel's Bluetooth Network Encapsulation Protocol (BNEP) subsystem. The flaw resides in bnep_rx_frame() and bnep_rx_control() within net/bluetooth/bnep/core.c. A BNEP peer can transmit a short BNEP Service Data Unit (SDU), causing the kernel to dereference the packet type byte, control opcode, and UUID-size byte before verifying their presence. KASAN reproduction confirmed a slab-out-of-bounds read of size 1 in bnep_rx_frame, with the buggy address located adjacent to a 1-byte kmalloc-8 allocation. The Linux kernel maintainers have resolved the issue across multiple stable branches.

Critical Impact
A paired or proximate Bluetooth peer can send a malformed short BNEP frame to trigger a kernel out-of-bounds read, leading to information disclosure or kernel denial of service.

Affected Products

Linux kernel Bluetooth subsystem (BNEP module, net/bluetooth/bnep/core.c)
Multiple upstream stable kernel branches receiving the backported fixes
Linux distributions shipping vulnerable kernel versions with Bluetooth PAN/BNEP enabled

Discovery Timeline

2026-06-25 - CVE-2026-53253 published to NVD
2026-06-25 - Last updated in NVD database

Technical Details for CVE-2026-53253

Vulnerability Analysis

The Bluetooth Network Encapsulation Protocol (BNEP) allows Ethernet-like framing over Bluetooth L2CAP for Personal Area Networking (PAN) profiles. The handler bnep_rx_frame() reads the BNEP packet type byte immediately upon receiving an sk_buff. For control packets, the code subsequently reads the control opcode and the setup UUID-size byte without first verifying that these bytes exist in the buffer. Similarly, bnep_rx_control() dereferences the control opcode without rejecting an empty control payload.

When a BNEP peer transmits a truncated SDU, the kernel reads beyond the bounds of the allocated slab object. KASAN flagged a read of size 1 located zero bytes to the right of a 1-byte allocation in kmalloc-8, confirming the boundary violation in the receive path executed by process_one_work.

Root Cause

The root cause is missing length validation before pointer dereference in the BNEP receive path. The parser assumed minimum frame size invariants that an attacker-controlled peer is not required to honor. The fix introduces skb_pull_data() for the fixed fields in bnep_rx_frame() so that a NULL return gates each dereference. The control handler is split so the frame path can pass an opcode that has already been pulled, while a byte-buffer wrapper handles extension control payloads. For BNEP_SETUP_CONN_REQ, the UUID-size byte is named before pulling the setup payload, and the destination/source service UUID tuple is documented explicitly.

Attack Vector

Exploitation requires the ability to send a crafted BNEP frame to a target system with an active BNEP/PAN session. An adjacent attacker with Bluetooth radio range and an established or accepted L2CAP connection to the BNEP PSM can deliver the malformed short SDU. The resulting out-of-bounds read can leak adjacent kernel memory or crash the kernel, depending on the slab layout at the time of the read.

No verified public proof-of-concept code is available. The KASAN call trace published with the patch documents the faulting path through bnep_rx_frame+0x130c/0x1790 originating from worker_thread and process_one_work. Refer to the upstream kernel patch series for technical details of the fix.

Detection Methods for CVE-2026-53253

Indicators of Compromise

KASAN reports referencing slab-out-of-bounds in bnep_rx_frame in kernel logs (dmesg, journalctl -k).
Unexpected kernel oops or panic traces involving net/bluetooth/bnep/core.c and process_one_work.
Repeated short or malformed BNEP frames observed in Bluetooth HCI snoop logs (btmon, hcidump).

Detection Strategies

Audit running kernel versions across the fleet against the fixed commits and flag hosts still running pre-patch builds with the bnep module loaded.
Monitor for the bnep kernel module being loaded on systems that do not require Bluetooth PAN functionality.
Correlate Bluetooth pairing events with subsequent kernel warnings or crashes to identify potential exploitation attempts.

Monitoring Recommendations

Forward kernel ring buffer messages to a centralized log platform and alert on KASAN, BUG, or oops signatures referencing bnep_.
Track lsmod | grep bnep results across endpoints and servers to identify exposure surface.
Enable Bluetooth subsystem auditing on hosts that must run BNEP to capture peer addresses associated with anomalous frames.

How to Mitigate CVE-2026-53253

Immediate Actions Required

Apply the upstream Linux kernel patches referenced in this advisory or install distribution-provided kernel updates that incorporate the fix.
Unload the bnep kernel module on systems that do not need Bluetooth PAN: modprobe -r bnep.
Disable the Bluetooth service entirely on servers and workstations that do not require it: systemctl disable --now bluetooth.
Restrict Bluetooth pairing to known devices and disable discoverable mode on systems that must keep Bluetooth enabled.

Patch Information

The Linux kernel maintainers have released fixes across multiple stable branches. The patches modify net/bluetooth/bnep/core.c to use skb_pull_data() for fixed-field validation and to split the control handler. Relevant commits include:

Workarounds

Blacklist the bnep module via /etc/modprobe.d/blacklist-bnep.conf to prevent it from loading at boot.
Use a host firewall or Bluetooth management policy to block inbound BNEP/PAN profile connections from untrusted peers.
Physically disable Bluetooth radios on systems where the functionality is not operationally required.

bash

# Configuration example: prevent the vulnerable BNEP module from loading
echo "blacklist bnep" | sudo tee /etc/modprobe.d/blacklist-bnep.conf
sudo modprobe -r bnep
# Verify the module is no longer loaded
lsmod | grep bnep