CVE-2026-31511

What it actually does

This is a local Linux kernel use-after-free in the Bluetooth management subsystem. A pending management command can be freed without first being unlinked from the pending-command list when the add-advertising-patterns-monitor completion path handles certain non-canceled status values. Later list traversal, such as Bluetooth power-off handling or another pending-command validation, can dereference the freed object. In kernel context, that can result in memory corruption, kernel crash, or potentially local privilege escalation with confidentiality, integrity, and availability impact.

Why it matters to the business

Systems with affected Linux kernels and Bluetooth management functionality exposed to local users may be vulnerable to local denial of service or privilege escalation. The issue is not remotely exploitable by itself and has low EPSS with no known KEV listing or public exploit maturity in the provided data, but successful exploitation could allow a low-privileged local user or compromised process to take over the host. Impact is highest on laptops, workstations, edge devices, IoT devices, and servers with Bluetooth enabled or accessible to untrusted local workloads.

How an attack unfolds

An attacker first needs local access with enough privileges to interact with the Linux Bluetooth management interface. They then trigger Bluetooth management operations involving advertising pattern monitor handling in a sequence that causes the completion handler to free a pending command while it remains linked in the internal pending-command list. After the freed object remains reachable, the attacker triggers a subsequent Bluetooth management list traversal, such as power state changes or another pending-command validation. The kernel then dereferences freed memory. Depending on allocator state and exploit reliability, this may only crash the kernel, but a more controlled attack could attempt to reclaim the freed memory with attacker-influenced data and convert the use-after-free into kernel code execution or privilege escalation.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the Bluetooth MGMT dangling-pointer/use-after-free in mgmt_add_adv_patterns_monitor_complete. No exact fixed package versions were provided in the input, so use the fixed kernel versions published by the relevant Linux distribution or appliance vendor. Where immediate patching is not possible, reduce exposure by disabling Bluetooth on systems that do not require it, unloading or blocking Bluetooth kernel modules where operationally feasible, restricting local shell/container access to trusted users, and ensuring untrusted workloads cannot access host Bluetooth management interfaces. Reboots are typically required for kernel updates to take effect unless a validated live-patch is available.

How to confirm the fix worked

Verify that systems are running a vendor kernel version that includes the fix, not merely that packages have been downloaded. Confirm after reboot with the running kernel version and vendor advisory mapping. Validate that Bluetooth is disabled or modules are not loaded on systems using mitigation instead of patching. On representative systems, check whether Bluetooth management interfaces are present and whether local users or containers can access them. Review kernel changelogs or distribution advisories for references to the Bluetooth MGMT fix, mgmt_add_adv_patterns_monitor_complete, mgmt_pending_valid, or dangling pointer handling.

Typical attack path

1. Obtain local code execution on an affected Linux system, for example as a low-privileged user or compromised local service.
2. Confirm Bluetooth support is present and the Bluetooth management interface is reachable.
3. Issue crafted Bluetooth management operations related to advertising pattern monitor setup/completion to reach the vulnerable completion path.
4. Cause the pending command object to be freed without being removed from the pending-command list.
5. Trigger another Bluetooth management operation or Bluetooth power transition that traverses the stale list entry.
6. Abuse the resulting use-after-free to crash the kernel or attempt local privilege escalation through controlled memory reuse.

How to detect it

Look for evidence of prior exploitation primarily in kernel logs and crash artifacts, because exploitation is local and may manifest as crashes or memory-corruption warnings rather than obvious network indicators. Review journald, syslog, dmesg, kernel ring buffer captures, pstore/ramoops, vmcore crash dumps, and endpoint telemetry for Bluetooth management call traces, KASAN use-after-free reports, slab corruption, general protection faults, or panics around Bluetooth power-off or advertising monitor operations. Correlate suspicious crashes with local user sessions, recent execution of Bluetooth tooling, container/device access to Bluetooth interfaces, and repeated Bluetooth enable/disable events. There are no known threat actors, ransomware use, or KEV exploitation noted in the supplied data, so detection should focus on behavioral and crash-forensic evidence rather than campaign-specific indicators.

• mgmt_add_adv_patterns_monitor_complete
• mgmt_pending_valid
• mgmt_pending_free
• mgmt_pending_foreach
• __mgmt_power_off
• Bluetooth: MGMT
• KASAN: use-after-free
• BUG: KASAN: use-after-free
• general protection fault
• kernel BUG at net/bluetooth/mgmt.c
• net/bluetooth/mgmt.c
• Bluetooth: hci
• bluetoothd
• btmgmt
• btmon

What your security team should do

• Prioritize patching affected Linux endpoints and devices with Bluetooth enabled or exposed to local users, especially multi-user systems, developer workstations, kiosks, edge devices, and IoT fleets.
• Disable Bluetooth on systems where it is not needed, and enforce this through configuration management or endpoint hardening baselines.
• Restrict local access and container/device passthrough that could expose host Bluetooth management interfaces to untrusted workloads.
• Monitor for kernel crashes, KASAN reports, general protection faults, or call traces involving Linux Bluetooth MGMT functions.
• Because current EPSS is very low, unchanged over 30 days, not KEV-listed, and has no known exploit maturity in the supplied data, schedule remediation according to kernel local privilege escalation policy while elevating priority for high-risk local-access environments.