CVE-2026-97975

Bluetooth: hci_sysfs: Fix NULL pointer dereference in device_del()

N/A
Published: September 25, 2026 at 10:23 AM UTC
Updated: October 21, 2026 at 01:21 PM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
N/A
Exploit prediction
EPSS 0.2%

Description

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.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

0f67ca2a80acf8b207240405b7f72d660665d3df27aabf27fd014ae037cc179c61b0bee7cff55b3d5.10.2315.15.1745.4.2976.1.1206.11.116.12.26.136.6.646894717a1ea363c5a27010ba604f957c309d282d7b277bd569bb6a2777f0014f84b4344f444fd49d91e2a2e4d1336333804cd31162984f01ad8cc70fa9584c897d1cba6265c78010bbb45ca5722c88bcde5a44f351ca7efd9add9851b218f5353e2224b7fb91ce37dc9a37ea23cf32b6d7b667004e93d4c5
Vendor states this is fixed in 9b851b09b392da68bd715601f10a5adb2d8d19b8 (fixed)
Vendor states this is fixed in 9e9ece97b8e716890793de261574b8efef7d8702 (fixed)
Vendor states this is fixed in eeabdb25c3209569367e99a85ca9a503b64a646d (fixed)
Affected range stops below 5.11, so it looks safe — our inference, not a vendor statement
Affected range stops below 5.16, so it looks safe — our inference, not a vendor statement
Affected range stops below 5.5, so it looks safe — our inference, not a vendor statement
Affected range stops below 6.12, so it looks safe — our inference, not a vendor statement
Vendor states this is fixed in 6.12.114 (unaffected)
Vendor states this is fixed in 6.13 (unaffected)
Vendor states this is fixed in 6.18.53 (unaffected)
Affected range stops below 6.2, so it looks safe — our inference, not a vendor statement
Vendor states this is fixed in 6.6.160 (unaffected)
Affected range stops below 6.7, so it looks safe — our inference, not a vendor statement
Vendor states this is fixed in 7.2.7 (unaffected)
Vendor states this is fixed in 7.3 (unaffected)
Vendor states this is fixed in 7.3-rc3 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

Quick Info

StatusRECEIVED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card