CVE-2024-56604

What it actually does

A use-after-free occurs in rfcomm_sock_alloc() because bt_sock_alloc() attaches the sk object to the sock before rfcomm_dlc_alloc() can fail; the sk is then released while the dangling pointer remains, allowing later dereference of freed memory.

Why it matters to the business

Linux kernel systems using Bluetooth RFCOMM face risk of crashes or potential privilege escalation that can disrupt device connectivity, require reboots, and increase exposure on widely deployed kernels; the low EPSS and absence of KEV status indicate limited observed exploitation but the flaw affects core kernel code with high downstream prevalence.

How an attack unfolds

An attacker triggers rfcomm_sock_alloc() under conditions that cause bt_sock_alloc() to succeed and attach the sk, then forces rfcomm_dlc_alloc() to fail so the sk is freed while the pointer in the sock object is left dangling; subsequent access to that pointer results in use-after-free.

How to fix it

Upgrade the Linux kernel to a version containing commit ac3eaac4cf142a15fe67be747a682b1416efeb6e; rebuild and deploy updated kernel packages across all affected stable trees.

How to confirm the fix worked

Confirm the fix by verifying commit ac3eaac4cf142a15fe67be747a682b1416efeb6e is present in the kernel source tree or by checking that the order of bt_sock_alloc() and rfcomm_dlc_alloc() calls has been swapped in rfcomm_sock_alloc().

Typical attack path

1. Open an RFCOMM socket to invoke rfcomm_sock_alloc()
2. Arrange for bt_sock_alloc() to attach the sk pointer
3. Cause rfcomm_dlc_alloc() to fail
4. Trigger code paths that dereference the now-dangling sk pointer

How to detect it

Review kernel logs for oops, panics, or warnings mentioning rfcomm_sock_alloc or dangling sk pointers; correlate with unusual Bluetooth RFCOMM socket activity on systems that have not yet applied the fix.

What your security team should do

• Prioritize kernel updates containing ac3eaac4cf142a15fe67be747a682b1416efeb6e on all Bluetooth-enabled systems
• Test the updated kernel in staging environments before broad rollout
• Monitor kernel logs for Bluetooth RFCOMM-related oops or use-after-free reports until patching is complete