CVE-2025-39861

What it actually does

Use-after-free vulnerability in the Linux kernel Bluetooth vhci driver where debugfs files (force_suspend, force_wakeup, etc.) remain accessible after vhci_data is freed in vhci_release() but before hdev->debugfs is cleaned up in hci_release_dev().

Why it matters to the business

Local attackers on affected Linux systems may crash the kernel or attempt privilege escalation, disrupting Bluetooth-dependent services, containers, or virtualized environments and requiring urgent patching to maintain system stability.

How an attack unfolds

An attacker with local access opens a vhci device, triggers vhci_release() to free the backing structure while debugfs entries still reference it, then performs operations on the dangling debugfs files to read or write freed memory; related campaigns such as VMSCAPE have targeted similar kernel surfaces for container escape.

How to fix it

Update the Linux kernel to the fixed commit bd75eba88e88d7b896b0c737b02a74a12afc235f or later stable releases that move debugfs creation to a dedicated function and explicitly remove files in vhci_release() before freeing associated structures.

How to confirm the fix worked

Confirm the running kernel contains commit bd75eba88e88d7b896b0c737b02a74a12afc235f; inspect vhci.c to verify debugfs removal occurs in vhci_release() prior to kfree of vhci_data; test by creating and releasing vhci devices while monitoring for UAF warnings in dmesg.

Typical attack path

1. Obtain local user access on a system with the vulnerable vhci module loaded
2. Interact with /dev/vhci or related Bluetooth HCI interfaces to allocate a vhci device
3. Trigger device release to free vhci_data while debugfs files persist
4. Access lingering debugfs entries under hdev->debugfs to trigger use-after-free
5. Leverage resulting memory corruption for denial of service or code execution

How to detect it

Review kernel logs (dmesg, /var/log/kern.log) for use-after-free warnings or slab errors involving vhci_data or hci debugfs; correlate with process activity opening /dev/vhci or accessing Bluetooth debugfs entries around the time of any crash or anomaly.

What your security team should do

• Prioritize kernel upgrades on all systems exposing Bluetooth or vhci interfaces, especially container hosts
• Restrict unprivileged local access to Bluetooth device nodes until patched
• Monitor kernel logs for use-after-free warnings related to hci or vhci debugfs
• Apply the fix across all stable branches referenced in the GIT repository