CVE-2023-53520

What it actually does

Race condition between hci_unregister_dev freeing the hci_dev object and hci_suspend_notifier still referencing it, resulting in a use-after-free crash inside hci_suspend_sync during power management suspend paths.

Why it matters to the business

Unexpected system crashes on Linux hosts using Bluetooth during suspend/resume cycles, causing loss of availability for laptops, desktops, and container hosts; low urgency given stable EPSS and absence from KEV.

How an attack unfolds

An attacker with local access triggers concurrent hci device unregistration and a system suspend event so that the notifier chain dereferences a freed hci_dev structure, producing a kernel panic; no named threat actors are known to be exploiting this specific flaw.

How to fix it

Upgrade the Linux kernel to a version containing commit e1fa25a91091bbed691ba2996a6cee809e3309a2 or apply the equivalent stable backport; Debian 11/12/13/14 users should install linux 5.10.46-1 or newer packages; rebuild and reboot with the patched kernel.

How to confirm the fix worked

Confirm the running kernel contains the referenced commit or package version; attempt to reproduce the original call trace under concurrent unregister + suspend workloads and verify the crash no longer occurs; monitor dmesg for absence of hci_suspend_sync faults.

Typical attack path

1. Obtain local user or container access on an affected Linux kernel
2. Unload or unregister a Bluetooth HCI device while a suspend operation is in progress
3. Force a PM suspend via /sys/power/state or equivalent to invoke the notifier chain
4. Trigger the race so hci_suspend_sync accesses the already-freed hci_dev object
5. Cause kernel panic and denial of service

How to detect it

Search kernel logs for the exact call trace containing hci_suspend_sync, hci_suspend_dev, and hci_suspend_notifier during pm_suspend; correlate with Bluetooth device removal events; examine auditd or systemd logs for concurrent suspend and hci device unregister operations.

What your security team should do

• Prioritize patching kernel packages on all Bluetooth-enabled systems within standard maintenance windows
• Add the fixed commit hash to internal kernel build pipelines and CI tests
• Review power-management and Bluetooth device lifecycle code for similar reference-counting issues
• Update EPSS and threat intel feeds; no immediate KEV-driven emergency action required