CVE-2024-46868

What it actually does

Failure to release a lock on the error path in qcuefi_acquire when the __qcuefi pointer is unset creates a deadlock on subsequent acquisition attempts.

Why it matters to the business

Systems may experience hangs or unresponsiveness during firmware operations on affected Qualcomm-based Linux devices, increasing downtime risk for high-availability workloads; low exploitability and no known active campaigns reduce immediate urgency.

How an attack unfolds

An attacker with local access triggers concurrent calls to the affected function under conditions where the pointer remains unset, causing the held lock to block all future callers and induce a deadlock state.

How to fix it

Update the Linux kernel to a version containing commit 8c6a5a1fc02ad1d62d06897ab330693d4d27cd03 or later; rebuild and deploy the fixed kernel image across affected devices.

How to confirm the fix worked

Verify the presence of the fix commit in the running kernel source or confirm the updated package version via package manager; test concurrent firmware acquisition paths to ensure no deadlock occurs.

Typical attack path

1. Obtain local execution context on the target system
2. Trigger repeated invocations of qcuefi_acquire in parallel
3. Force the error path where the pointer check fails
4. Observe system-wide lock contention leading to unresponsiveness

How to detect it

Inspect kernel logs and dmesg output for repeated lock acquisition failures or hung task warnings involving qcuefi; correlate with process activity invoking UEFI secure app interfaces.

What your security team should do

• Apply the kernel update containing the referenced commit within standard maintenance windows
• Monitor for deadlock-related kernel logs on Qualcomm UEFI firmware paths
• Review device firmware interaction code for similar lock-handling patterns