CVE-2024-40977

What it actually does

Deadlock between reset_work holding a lock while waiting for stat_worker to park, and stat_worker waiting for the same lock, during mt7921s chip recovery in the Linux kernel wifi driver.

Why it matters to the business

System instability, hung task reports, and potential forced reboots on Linux devices using affected mt7921s wifi hardware, reducing availability for users and operations.

How an attack unfolds

An attacker with local access or the ability to trigger wifi chip reset conditions (such as through crafted network traffic or hardware events) can induce the deadlock state between kernel worker threads, causing the system to hang.

How to fix it

Update the Linux kernel to a version containing commit 0b81faa05b0b9feb3ae2d69be1d21f0d126ecb08 or later in the stable tree; apply the patch that prevents stat_worker execution during chip recovery.

How to confirm the fix worked

Confirm the presence of the fix commit in the running kernel source; test chip reset scenarios to verify no deadlock occurs and stat_worker is properly parked.

Typical attack path

1. Trigger conditions that initiate chip recovery in the mt7921s driver
2. Allow reset_work to acquire the contended lock and wait for stat_worker
3. Cause stat_worker to block on the same lock, creating the deadlock
4. Observe hung task messages and potential system reboot

How to detect it

Search kernel logs for hung task dumps mentioning reset_work or stat_worker during wifi chip recovery events; inspect dmesg or syslog for deadlock indicators on affected hardware.

What your security team should do

• Prioritize kernel updates on all systems using mt7921s hardware within maintenance windows
• Monitor for kernel hung task logs related to wifi recovery
• Review wireless driver usage in high-availability environments for exposure