CVE-2024-44962

What it actually does

Race condition in btnxpuart Bluetooth driver where del_timer_sync() during module unload can allow the timer to be rearmed and invoked after the driver code has been removed, resulting in a kernel panic via a call to freed memory.

Why it matters to the business

Unexpected system crashes and reboots on devices using this Bluetooth driver, leading to service disruption, potential data corruption, and operational downtime especially in embedded or automotive Linux systems.

How an attack unfolds

A local attacker with sufficient privileges unloads the btnxpuart module while a timer callback is simultaneously being modified, triggering the use-after-unload condition that panics the kernel.

How to fix it

Update the Linux kernel to a version containing commit 4d9adcb94d55e9be8a3e464d9f2ff7d27e2ed016 or later stable releases that replace del_timer_sync() with timer_shutdown_sync() in the btnxpuart driver.

How to confirm the fix worked

Confirm the running kernel contains the timer_shutdown_sync() change in drivers/bluetooth/btnxpuart.c and verify module unload no longer produces timer-related kernel panics under load.

Typical attack path

1. Obtain local access or code execution with module-unload privileges
2. Trigger or wait for btnxpuart driver activity that arms a timer
3. Unload the btnxpuart module at the precise moment the timer may be modified
4. Observe resulting kernel oops and panic from the timer firing post-unload

How to detect it

Search kernel logs and dmesg for oops traces showing call_timer_fn after btnxpuart unload, internal errors with code 0000000086000007, and modules lists that include btnxpuart as the last unloaded module.

• Internal error: Oops: 0000000086000007
• last unloaded: btnxpuart
• Kernel panic - not syncing: Oops: Fatal exception in interrupt
• call_timer_fn.isra.0

What your security team should do

• Prioritize kernel updates on all affected systems within standard patch windows given low EPSS and no KEV listing
• Restrict unprivileged module unloading via kernel module signing and capability controls where feasible
• Monitor for kernel oops logs referencing btnxpuart during driver unload events