CVE-2026-53209

What it actually does

This is a Linux kernel Bluetooth buffer overflow in the HCI synchronization path for LE extended advertising. An advertising instance can already contain the maximum supported extended advertising payload; when the kernel prepends Broadcast Announcement service data, the combined payload can exceed the temporary rebuild buffer and overwrite adjacent kernel memory. Depending on kernel configuration, memory layout, and triggerability, the likely outcomes are Bluetooth subsystem failure, kernel crash, denial of service, or potentially broader kernel memory corruption. Practical exploitation generally requires the ability to create or modify Bluetooth advertising instances through local Bluetooth management/HCI interfaces, which are usually restricted to privileged local users or system Bluetooth services.

Why it matters to the business

Systems using Linux Bluetooth advertising features may be exposed to local denial-of-service risk and, in worst cases, kernel-level memory corruption. The most affected environments are Bluetooth-enabled endpoints, embedded Linux devices, gateways, kiosks, IoT products, and systems where local users, containers, services, or applications can interact with Bluetooth management interfaces. Current public exploitation signals are low: EPSS is very low, there is no known CISA KEV listing, no ransomware association, and no reported mature public exploit. However, because the flaw is in kernel code, successful exploitation can have high operational impact if it crashes devices or disrupts Bluetooth-dependent services.

How an attack unfolds

An attacker first needs a path to control Bluetooth advertising configuration on a vulnerable Linux system, typically by gaining local access with sufficient privileges, compromising a process that already manages Bluetooth, or abusing an overly permissive Bluetooth management interface. The attacker then creates or identifies an extended advertising instance whose payload is already at or near the maximum supported size. They trigger the code path that prepends Broadcast Announcement service data to that existing payload. On vulnerable kernels, the kernel rebuilds the advertising data in a temporary buffer without rejecting the oversized combined payload first, allowing the copy operation to exceed the buffer boundary. The immediate result may be memory corruption in kernel space, often observed as Bluetooth malfunction, kernel warnings, KASAN reports, an Oops, or a full system panic. On fixed kernels, the oversized case is rejected before copying and the existing advertising data remains intact.

How to fix it

Upgrade to a vendor-supported Linux kernel that includes the upstream fix for rejecting oversized Broadcast Announcement prepend operations before copying advertising data. If a patched kernel is not immediately available, reduce exposure by disabling Bluetooth on systems that do not require it, disabling or unloading Bluetooth kernel modules such as bluetooth and btusb where operationally acceptable, blocking untrusted users and containers from accessing Bluetooth management/HCI sockets, and limiting CAP_NET_ADMIN or equivalent privileges to trusted system services only. For embedded products, rebuild and ship firmware with the patched kernel and validate that Bluetooth advertising functionality still behaves correctly after oversized payload rejection.

How to confirm the fix worked

Confirm the running kernel package or firmware build includes the Bluetooth HCI sync fix for oversized Broadcast Announcement prepending. Where source validation is possible, verify that the Broadcast Announcement advertising path checks the combined size of existing advertising data plus prepended service data before performing the copy into the temporary buffer. Operationally, test on a non-production system by configuring an extended advertising payload at the maximum supported size and then enabling the Broadcast Announcement path; a fixed kernel should reject the operation cleanly, preserve the existing advertising data, and avoid kernel warnings, KASAN findings, Oops messages, or crashes. Also verify that Bluetooth is disabled or access-restricted on systems where it is not required.

Typical attack path

1. Obtain local execution or compromise a service with permission to configure Bluetooth advertising.
2. Confirm that Bluetooth and LE extended advertising support are enabled on the target system.
3. Create or modify an advertising instance so the existing extended advertising payload is at or near the maximum allowed size.
4. Trigger Broadcast Announcement handling so the kernel attempts to prepend Broadcast Announcement service data.
5. Cause the vulnerable kernel to copy the oversized combined payload into a temporary buffer.
6. Observe or leverage resulting kernel memory corruption, Bluetooth service disruption, kernel Oops, or system crash.

How to detect it

Look for signs of prior exploitation or testing in kernel logs, system journals, crash dumps, and Bluetooth service logs. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, systemd-coredump metadata, pstore/ramoops, kdump/vmcore records, bluetoothd logs, audit logs for privileged Bluetooth tooling, and EDR telemetry showing local processes interacting with Bluetooth management interfaces before a crash. Focus on sequences where Bluetooth advertising configuration is followed by kernel memory-corruption diagnostics, KASAN slab-out-of-bounds reports, kernel Oops messages, BUG/WARNING traces in Bluetooth HCI code, unexpected bluetoothd restarts, or system reboots. Because no public exploit-specific payload or threat actor pattern is known, detection should emphasize behavioral correlation: privileged local Bluetooth configuration activity plus kernel fault artifacts involving Bluetooth, HCI, extended advertising, or Broadcast Announcement handling.

• Broadcast Announcement
• hci_adv_bcast_annoucement
• hci_adv_bcast_announcement
• Bluetooth: hci
• extended advertising
• advertising data
• slab-out-of-bounds
• KASAN: slab-out-of-bounds
• KASAN: out-of-bounds
• BUG: KASAN
• kernel BUG
• kernel NULL pointer dereference
• general protection fault
• Oops:
• Kernel panic
• bluetoothd
• btmgmt
• hciconfig
• btmon
• /var/log/kern.log
• /var/log/messages
• /sys/fs/pstore
• /proc/vmcore

What your security team should do

• Inventory Linux systems with Bluetooth enabled, prioritizing endpoints, embedded devices, gateways, kiosks, and IoT devices that use LE advertising.
• Patch affected systems through vendor kernel updates or firmware updates as soon as practical, especially where local users or third-party applications can interact with Bluetooth.
• Temporarily disable Bluetooth on systems that do not require it, or unload Bluetooth modules where compatible with business operations.
• Restrict access to Bluetooth management/HCI interfaces and review assignments of CAP_NET_ADMIN, privileged containers, and services that can control Bluetooth.
• Monitor kernel logs for Bluetooth-related crashes, KASAN reports, slab out-of-bounds findings, Oops events, and unexpected reboots.
• Treat repeated Bluetooth-triggered kernel faults as suspicious and preserve logs, crash dumps, and kernel versions for forensic review.
• For product teams, add regression tests covering maximum-size LE extended advertising payloads combined with Broadcast Announcement service data.