CVE-2024-57879

What it actually does

Missing hci_dev_put call after hci_get_route in iso_listen_bis leaves an elevated reference count on the Bluetooth device, causing a reference-count leak that can lead to use-after-free or other memory corruption conditions in the kernel Bluetooth ISO subsystem.

Why it matters to the business

Kernel memory corruption in Bluetooth handling can trigger system crashes, denial of service, or potential local privilege escalation on Linux systems using Bluetooth ISO sockets; the issue affects the upstream kernel and any distributions that have not applied the referenced commit, increasing operational risk for devices relying on Bluetooth audio or data streams.

How an attack unfolds

An attacker with local access triggers the iso_listen_bis path (for example by creating a Bluetooth ISO listening socket) so that hci_get_route succeeds but an error return occurs before hci_dev_put, leaving the device reference elevated; repeated triggering can exhaust references or create a window for use-after-free when the device is later freed.

How to fix it

Update the Linux kernel to the commit a38297e3fb012ddfa7ce0321a7e5a8daeb1872b6 or later; rebuild and deploy the patched kernel image, then reboot affected systems. Where distribution backports exist, apply the vendor-supplied kernel update instead.

How to confirm the fix worked

Confirm the running kernel contains commit a38297e3fb012ddfa7ce0321a7e5a8daeb1872b6 (via git log or kernel version string); test that iso_listen_bis paths now consistently call hci_dev_put on all return paths; monitor for Bluetooth ISO socket creation under error conditions to verify reference counts remain balanced.

Typical attack path

1. Obtain local user access on a Linux system with Bluetooth support
2. Create or connect a Bluetooth ISO socket that exercises iso_listen_bis
3. Force an error path after hci_get_route but before the missing hci_dev_put
4. Repeat to induce reference leak or race a subsequent device release
5. Leverage resulting memory corruption for denial of service or escalation

How to detect it

Search kernel logs and audit trails for Bluetooth ISO socket creation errors around iso_listen_bis; look for repeated hci_get_route calls without corresponding device release messages; monitor for Bluetooth-related oops or use-after-free reports in dmesg after socket operations.

What your security team should do

• Prioritize kernel update on any system exposing Bluetooth ISO functionality
• Apply the fix within standard change windows; treat as memory-safety defect
• Verify update success by checking kernel commit or version after reboot
• Review Bluetooth usage and disable ISO sockets if not required