Bluetooth: hci_sysfs: Fix NULL pointer dereference in device_del()
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 6.6.160, 6.12.114, 5.5, 5.11, 5.16, and 4 more
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
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.
Timeline
- CVE published
- Record last updated
Affected versions
- Linux Linux
From de5a44f351ca7efd9add9851b218f5353e2224b7 · fixed in 55b76500546e5f2e7fdd7ae7283530b620de6e61; From 7b277bd569bb6a2777f0014f84b4344f444fd49d · fixed in 66cc55b69928b742d24b4c5b66d195ae96900e48; From 27aabf27fd014ae037cc179c61b0bee7cff55b3d · fixed in eeabdb25c3209569367e99a85ca9a503b64a646d; From 27aabf27fd014ae037cc179c61b0bee7cff55b3d · fixed in 9e9ece97b8e716890793de261574b8efef7d8702; From 27aabf27fd014ae037cc179c61b0bee7cff55b3d · fixed in 9b851b09b392da68bd715601f10a5adb2d8d19b8; From 6.6.64 · fixed in 6.6.160; From 6.12.2 · fixed in 6.12.114; From 5.4.297 · fixed in 5.5; From 5.10.231 · fixed in 5.11; From 5.15.174 · fixed in 5.16; From 6.1.120 · fixed in 6.2; From 6.11.11 · fixed in 6.12
- Linux Linux
6.13
- KernelLinux
fixed in 6.6.160; From 6.7.0 · fixed in 6.12.114; From 6.13.0 · fixed in 6.18.53; fixed in 7.2.7