CVE-2026-97975 in Linux
Summary
by MITRE • 09/25/2026
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_sysfs: Fix NULL pointer dereference in device_del()
A NULL pointer dereference in klist_put() occurs when a child device (such as a BNEP network device in bnep_session) is concurrently being unregistered while hci_conn_del_sysfs() reparents child devices.
This is caused by a race condition between hci_conn_del_sysfs() and concurrent child device unregistration (e.g. bnep_session calling unregister_netdev()). During device unregistration, device_del() snapshots a non-NULL parent pointer. Concurrently, hci_conn_del_sysfs() finds the child device using device_find_any_child() and calls device_move() to reparent it to NULL, which removes the node from its parent's klist and clears knode_parent. Subsequently, device_del() calls klist_del(&dev->p->knode_parent) using the stale parent snapshot, causing klist_put() to dereference knode_klist(n)->put on an already removed node, resulting in a NULL pointer dereference.
This race was introduced by commit 27aabf27fd01 ("Bluetooth: fix use-after-free in device_for_each_child()"), which replaced device_find_child(..., __match_tty) with device_find_any_child() in hci_conn_del_sysfs(). That change was intended to avoid a use-after-free where conn->dev outlived its parent hdev->dev when child devices held references to conn->dev, because conn->dev only held a reference to hdev->dev while registered in sysfs.
Fix the issue properly by taking an explicit reference to the parent device with get_device(&hdev->dev) in hci_conn_init_sysfs() and dropping it with put_device(parent) in bt_link_release() when the conn device is freed. This ensures that hdev->dev remains valid for the entire lifecycle of conn->dev, resolving the underlying use-after-free. With the parent reference held properly, restore the __match_tty filter in hci_conn_del_sysfs() so that device_move() is only invoked on persistent RFCOMM TTY devices as originally intended, eliminating the race condition with unregistering network devices.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/25/2026
The Linux kernel Bluetooth subsystem contains a critical concurrency vulnerability involving NULL pointer dereference within the sysfs interface management code for HCI connections. This flaw manifests when handling device deletion and unregistration processes concurrently, specifically affecting child devices such as BNEP network interfaces associated with bnep sessions. The root cause lies in a race condition between the hci_conn_del_sysfs function and concurrent child device unregistration operations like unregister_netdev. During normal operation, the system attempts to reparent or remove child devices from their parent HCI device structures while those children are simultaneously being torn down by network stack components.
The technical mechanism of this failure begins when a child device initiates its deletion process via device_del(). At an early stage in this sequence, the kernel snapshots a pointer to the non-NULL parent device structure for later use during cleanup. Concurrently, hci_conn_del_sysfs executes and utilizes device_find_any_child() to locate the specific child device associated with the HCI connection being deleted. Upon finding it, the function calls device_move() to reparent the child device to NULL. This operation effectively removes the node from its parent's klist and clears the knode_parent field within the kernel object structure. Because this happens concurrently with the ongoing deletion of the same child device, the previously snapped parent pointer becomes stale relative to the current state of the kernel objects involved in the removal process.
When device_del() proceeds to complete its cleanup sequence, it attempts to call klist_del on the knode_parent using the now-stale snapshot of the parent reference. This leads directly into a call to klist_put(), which expects valid list structures and node references. However, because the node has already been removed from the parent's klist during the reparenting operation triggered by hci_conn_del_sysfs, the internal pointers within klist_put() become invalid or null. Consequently, the function attempts to dereference a NULL pointer when accessing knode_klist(n)->put, resulting in an immediate kernel panic or crash due to a NULL pointer dereference exception. This represents a significant stability issue that can be triggered by normal Bluetooth network interface lifecycle events under high concurrency conditions.
This vulnerability was inadvertently introduced by commit 27aabf27fd01, which aimed to fix a previous use-after-free bug in device_for_each_child(). That earlier patch replaced the usage of device_find_child with __match_tty filtering against device_find_any_child() within hci_conn_del_sysfs. The original intent was to prevent scenarios where conn->dev outlived its parent hdev->dev, as conn->dev only held a reference to hdev->dev while registered in sysfs. However, by broadening the scope of devices matched and moved without ensuring proper lifetime management of the parent device itself, the patch created this new race condition involving concurrent unregistration paths that were not previously affected because they did not trigger the reparenting logic under the same timing constraints.
The resolution involves a two-part fix addressing both the reference counting lifecycle and the filtering criteria for device movement. First, an explicit reference to the parent device is taken using get_device(&hdev->dev) during hci_conn_init_sysfs initialization. This ensures that the parent HCI device structure remains valid and immune to premature freeing for the entire duration of the child connection's existence. The corresponding put_device(parent) call is added in bt_link_release() when the connection device is finally freed, maintaining strict reference count balance. Second, with the underlying use-after-free risk mitigated by proper lifetime management, the code reverts to using the __match_tty filter within hci_conn_del_sysfs. This restricts device_move operations exclusively to persistent RFCOMM TTY devices as originally intended, thereby excluding transient network devices like BNEP from triggering the reparenting logic that causes the race condition.
From a security and standards perspective, this vulnerability aligns with CWE-416: Use After Free, specifically in contexts where concurrent access leads to dereferencing freed or invalid memory structures. It also relates to CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization, as the race condition arises from unsynchronized access to shared kernel object states during device lifecycle transitions. In terms of MITRE ATT&CK mapping for Linux systems, this falls under T1059.004: Unix Shell Commands or more broadly under system exploitation techniques involving local privilege escalation via kernel crashes if an attacker can trigger the specific Bluetooth interface state changes rapidly enough to exploit the window between snapshotting and deletion. While primarily a stability issue leading to denial of service through kernel panic, such race conditions in core subsystems are often precursors to more severe memory corruption vulnerabilities if similar patterns exist elsewhere without proper synchronization primitives like mutexes or RCU read-side critical sections protecting the parent pointer access during concurrent modification windows.
Mitigation strategies for system administrators and developers involve applying the upstream Linux kernel patch that implements these reference counting fixes and filter restrictions. For systems unable to update immediately, disabling Bluetooth network interfaces such as BNEP if not strictly required can reduce the attack surface by eliminating one of the primary vectors triggering the race condition during device unregistration. Additionally, ensuring that Bluetooth stack services are configured with appropriate resource limits may help mitigate potential denial-of-service impacts should a similar vulnerability be discovered in related subsystems before full patching is possible.