CVE-2026-97975
CVE CVE-2026-97975EUVD EUVD-2026-86629Published 2026-09-25T10:23:13.000Z
What the advisory describes
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.
Source: EUVD (ENISA), in the words of the advisory.
Products the advisory names
These come from the advisory itself, not from any check we performed.
- Linux — Linux 6.13; 27aabf27fd014ae037cc179c61b0bee7cff55b3d <eeabdb25c3209569367e99a85ca9a503b64a646d; patch: 6.18.53; 27aabf27fd014ae037cc179c61b0bee7cff55b3d <9e9ece97b8e716890793de261574b8efef7d8702; patch: 7.2.7; patch: 0; 6.1.120 <6.2; 6.6.64 <6.7; a9584c897d1cba6265c78010bbb45ca5722c88bc; patch: 7.3-rc3; fb91ce37dc9a37ea23cf32b6d7b667004e93d4c5; 5.10.231 <5.11; 6894717a1ea363c5a27010ba604f957c309d282d; 6.11.11 <6.12; 91e2a2e4d1336333804cd31162984f01ad8cc70f; 0f67ca2a80acf8b207240405b7f72d660665d3df; 7b277bd569bb6a2777f0014f84b4344f444fd49d; 5.4.297 <5.5; 5.15.174 <5.16; de5a44f351ca7efd9add9851b218f5353e2224b7; 6.12.2 <6.13; 27aabf27fd014ae037cc179c61b0bee7cff55b3d <9b851b09b392da68bd715601f10a5adb2d8d19b8
The versions shown are the advisory's own. Patchlage compares no version numbers and derives no judgement from them — which version is installed is something a person has to look up.
Carried in the product catalogue
An estate covering these products can be recorded in Patchlage. An advisory about them appears in the next morning's situation report.
- Linux — Linux
Does this concern one of your customers?
This page cannot answer that — it does not know your estate. Whoever has recorded their environments gets the answer the morning after publication, together with a paragraph they can forward to the customer unedited.
Try it for 28 daysPatchlage reports hits and suspected hits. About everything else this system says nothing — neither this page nor the situation report ever claims that an estate is safe.