CVE-2022-48844

What it actually does

Use-after-free in Bluetooth HCI core caused by failing to release the sent_cmd skb before freeing the hci_dev structure, allowing the kernel to reuse or corrupt the leaked memory contents.

Why it matters to the business

Local attackers can trigger kernel memory corruption or denial-of-service on Linux systems that use Bluetooth, potentially crashing devices or services and requiring reboots; the issue affects the widely used Linux kernel across servers, desktops, and embedded devices.

How an attack unfolds

An attacker with local access loads or triggers Bluetooth HCI operations that allocate a sent_cmd skb, then forces hci_dev teardown without freeing the skb; subsequent use of the dangling pointer leads to memory corruption or crash. No public in-the-wild exploitation is recorded and the listed threat actor reference does not apply to this kernel memory leak.

How to fix it

Upgrade the Linux kernel to the commit 3679ccc09d8806686d579095ed504e045af7f7d6 or later stable releases that contain the fix; rebuild and reboot all affected systems. Where immediate patching is not possible, disable the Bluetooth subsystem via kernel configuration or blacklist the hci_core module.

How to confirm the fix worked

Confirm the running kernel contains commit 3679ccc09d8806686d579095ed504e045af7f7d6 or a backport; inspect /proc/version or uname output and verify the Bluetooth hci_dev teardown path no longer leaks sent_cmd objects via code review or memory-leak tooling.

Typical attack path

1. Obtain local shell or user context on a Linux host with Bluetooth support
2. Trigger repeated Bluetooth HCI command paths that allocate sent_cmd skbs
3. Force hci_dev unregistration or module unload while skbs remain referenced
4. Reuse the freed memory region to cause kernel panic or corruption

How to detect it

Review kernel logs for Bluetooth HCI unregistration events followed by slab or page allocator warnings; look for repeated allocation patterns of hci_dev and sent_cmd objects without corresponding frees. No specific post-exploitation artifacts are known.

What your security team should do

• Apply the referenced kernel commit or distribution update within standard change windows
• Prioritize systems exposing Bluetooth interfaces or running Android-derived kernels
• Monitor EPSS and KEV feeds for any future rise in exploit maturity
• Temporarily disable Bluetooth where the functionality is not required