CVE-2023-28464 Overview
CVE-2023-28464 is a double free vulnerability in the Linux kernel Bluetooth subsystem affecting versions through 6.2.9. The flaw resides in the hci_conn_cleanup function in net/bluetooth/hci_conn.c. Repeated calls to hci_dev_put and hci_conn_put cause a use-after-free condition observed in hci_conn_hash_flush. A local authenticated attacker can exploit the double free to corrupt kernel memory and escalate privileges. The vulnerability is tracked under [CWE-415] (Double Free) and also affects multiple NetApp HCI storage firmware products that ship the affected kernel.
Critical Impact
Local attackers with low privileges can trigger memory corruption in the kernel Bluetooth stack, leading to privilege escalation and full system compromise.
Affected Products
- Linux kernel versions through 6.2.9, including 6.1.25, 6.2.12, and 6.3 release candidates (rc1 through rc6)
- NetApp HCI storage nodes: H300S, H410C, H410S, H500S, and H700S firmware
- Any downstream distribution shipping the affected net/bluetooth/hci_conn.c code
Discovery Timeline
- 2023-03-09 - Patch proposal posted to the Linux Kernel Mailing List
- 2023-03-28 - Public discussion on the Openwall OSS Security list
- 2023-03-31 - CVE-2023-28464 published to NVD
- 2023-05-17 - NetApp Security Advisory NTAP-20230517-0004 released
- 2024-11-21 - Last updated in NVD database
Technical Details for CVE-2023-28464
Vulnerability Analysis
The vulnerability stems from incorrect reference count handling during Bluetooth HCI connection teardown. The hci_conn_cleanup function calls both hci_dev_put and hci_conn_put on objects whose lifetime is already managed elsewhere in the cleanup path. This results in the same kernel object being freed twice. The subsequent use-after-free is observable from hci_conn_hash_flush, which iterates the connection hash and dereferences entries whose backing memory has already been returned to the allocator.
Double free conditions in the Linux kernel SLUB allocator are a well-understood primitive for privilege escalation. An attacker who can race a second allocation into the freed slot gains the ability to overlap kernel object types and overwrite function pointers or credentials structures.
Root Cause
The root cause is unbalanced reference counting in the Bluetooth HCI connection lifecycle. The cleanup path drops references that were never acquired by hci_conn_cleanup itself, leaving subsequent code paths operating on freed memory. The bug is classified as [CWE-415] Double Free.
Attack Vector
Exploitation requires local access and the ability to interact with the Bluetooth subsystem, typically through socket APIs in the AF_BLUETOOTH family. An unprivileged user who can open HCI sockets and trigger connection state transitions can reach the vulnerable cleanup path. No user interaction is required beyond the attacker's own actions. Successful exploitation yields kernel-mode code execution and privilege escalation to root.
No public proof-of-concept exploit is currently listed for this CVE, and it is not present on the CISA Known Exploited Vulnerabilities catalog. Technical details are available in the Linux Kernel Mailing List discussion and the Openwall thread.
Detection Methods for CVE-2023-28464
Indicators of Compromise
- Unexpected kernel oops or panic messages referencing hci_conn_cleanup, hci_conn_hash_flush, hci_dev_put, or hci_conn_put in dmesg or /var/log/kern.log
- KASAN reports indicating use-after-free or double-free in the Bluetooth subsystem when KASAN is enabled
- Unprivileged processes opening raw HCI sockets followed by abrupt termination or system instability
Detection Strategies
- Audit running kernel versions against the affected range (Linux kernel through 6.2.9) using uname -r across the fleet
- Enable kernel auditd rules for socket() calls with AF_BLUETOOTH family from non-Bluetooth service accounts
- Monitor for loading of the bluetooth, bnep, or hci_* kernel modules on systems that do not require Bluetooth functionality
Monitoring Recommendations
- Forward kernel logs and audit events to a centralized SIEM for correlation of crash signatures with user activity
- Alert on repeated process termination by SIGKILL or SIGSEGV from processes interacting with /dev/rfkill or HCI sockets
- Track privilege escalation indicators such as unexpected UID transitions to 0 following Bluetooth subsystem activity
How to Mitigate CVE-2023-28464
Immediate Actions Required
- Update the Linux kernel to a version that includes the fix from the upstream patch series posted on 2023-03-09
- For NetApp HCI customers, apply firmware updates per NetApp Security Advisory NTAP-20230517-0004
- On systems where Bluetooth is not required, blacklist the bluetooth kernel module to remove the attack surface entirely
- Restrict CAP_NET_RAW and CAP_NET_ADMIN capabilities to only the user accounts that legitimately require them
Patch Information
The upstream fix corrects the reference counting in hci_conn_cleanup so that hci_dev_put and hci_conn_put are not invoked on objects already released by the connection teardown path. Distribution vendors including Red Hat, Debian, Ubuntu, SUSE, and NetApp have backported the fix into their supported kernel branches. Apply distribution security updates as soon as they are available. Refer to the Linux Kernel Mailing List patch thread for the upstream commit.
Workarounds
- Disable the Bluetooth service with systemctl disable --now bluetooth.service on servers and workstations that do not need it
- Blacklist Bluetooth modules by adding install bluetooth /bin/true to /etc/modprobe.d/disable-bluetooth.conf
- Use seccomp or SELinux/AppArmor policies to deny AF_BLUETOOTH socket creation for untrusted processes
- Limit physical and remote shell access to trusted administrators, as exploitation requires local code execution
# Configuration example: disable and blacklist the Bluetooth stack
sudo systemctl disable --now bluetooth.service
cat <<'EOF' | sudo tee /etc/modprobe.d/disable-bluetooth.conf
blacklist bluetooth
blacklist btusb
blacklist bnep
install bluetooth /bin/true
EOF
sudo update-initramfs -u
uname -r # verify kernel version after reboot
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

