CVE-2024-46692

What it actually does

Race condition in Linux kernel Qualcomm SCM firmware handling allows get_wq_ctx() to be interrupted as a standard SMC call, leading to deadlock when multiple SMC calls contend for wait queue contexts.

Why it matters to the business

Systems using affected Linux kernels on Qualcomm platforms may experience hangs or unresponsiveness during firmware calls, requiring reboots and disrupting operations with low but non-zero likelihood of remote trigger.

How an attack unfolds

An attacker with local access triggers concurrent SMC calls; one sleeping call wakes and invokes get_wq_ctx() which is interrupted, allowing another pending call to deadlock the wait queue allocator and freeze the system.

How to fix it

Update the Linux kernel to commit cdf7efe4b02aa93813db0bf1ca596ad298ab6b06 or later stable releases that mark get_wq_ctx() as a fast atomic call; apply vendor backports where available.

How to confirm the fix worked

Verify kernel source contains the atomic fast-call marking for get_wq_ctx(), confirm no deadlock under concurrent SCM load tests, and check git log for the referenced commit on running systems.

Typical attack path

1. Obtain local code execution or user access on affected Linux kernel
2. Issue multiple concurrent Qualcomm SCM calls that enter sleep state
3. Force interruption of get_wq_ctx() during wake handling
4. Trigger allocation contention leading to permanent deadlock

How to detect it

Review kernel logs for SMC-related wait queue stalls or deadlock traces, monitor for repeated failed SCM call patterns, and inspect dmesg or journalctl output around firmware interaction events.

What your security team should do

• Prioritize kernel upgrade to the fixed commit on all Qualcomm-based Linux deployments
• Monitor EPSS and threat feeds for any rise in exploitation despite current low scores
• Test concurrent firmware call workloads in staging to validate deadlock prevention
• Restrict untrusted local access until patches are deployed