CVE-2024-26722

What it actually does

A code path in rt5645_jack_detect_work leaves the jd_mutex permanently held, causing subsequent invocations of the same work item to deadlock.

Why it matters to the business

Systems may experience audio subsystem hangs or full kernel deadlocks after repeated jack detection events, leading to reduced device availability and requiring reboots.

How an attack unfolds

An attacker with local access triggers repeated headphone jack insert/remove events or manipulates the codec state to exercise the unlocked-mutex path twice, resulting in deadlock; no remote or unauthenticated paths are known.

How to fix it

Update the Linux kernel to a fixed version containing commit 3dd2d99e2352903d0e0b8769e6c9b8293c7454b2 or later stable releases such as 4.19.307; rebuild and reboot with the patched kernel.

How to confirm the fix worked

Verify the running kernel contains the referenced commit or is at least version 4.19.307; inspect the rt5645 driver source for proper mutex unlock on all paths in rt5645_jack_detect_work.

Typical attack path

1. Obtain local execution or physical access to the target system
2. Trigger repeated rt5645 jack detection events via hardware or user-space audio APIs
3. Force the work function to take the error path that omits mutex release
4. Invoke the work item a second time while the mutex remains held to induce deadlock

How to detect it

Review kernel logs for repeated rt5645 workqueue entries without corresponding mutex release messages; examine stack traces showing threads blocked on jd_mutex; no public exploit artifacts are known.

What your security team should do

• Prioritize kernel updates on all systems using the rt5645 codec within the next maintenance window
• Monitor vendor advisories for backported fixes in distribution kernels
• Test audio functionality after patching to confirm jack detection continues to operate