CVE-2024-35953

What it actually does

Deadlock in ivpu context_xa due to missing XA_FLAGS_LOCK_IRQ during xarray initialization, allowing the lock to be acquired from process context and then re-acquired from IRQ context.

Why it matters to the business

Systems using affected Linux kernel versions with Intel VPU acceleration hardware may experience sudden freezes or require manual reboot, disrupting workloads and availability.

How an attack unfolds

An attacker or workload triggers concurrent access to the ivpu device context from both kernel threads and interrupt handlers; the missing IRQ-safe flag permits the second acquisition while the first holder is interrupted, causing deadlock. Threat actor references to Android kernel RCE appear unrelated to this specific locking flaw.

How to fix it

Update the Linux kernel to the commit d43e11d9c7fcb16f18bd46ab2556c2772ffc5775 or later stable releases that include the XA_FLAGS_LOCK_IRQ fix for context_xa initialization.

How to confirm the fix worked

Confirm the presence of XA_FLAGS_LOCK_IRQ in the ivpu device initialization code and verify no lockdep warnings related to context_xa under concurrent thread and IRQ access.

Typical attack path

1. Obtain code execution or workload control on a system running the vulnerable kernel with ivpu enabled.
2. Perform operations that allocate or manipulate ivpu contexts from process context.
3. Trigger an IRQ that also attempts to lock the same context_xa.
4. Observe deadlock reported by lockdep or system hang.

How to detect it

Review kernel logs for lockdep warnings or deadlock traces involving ivpu and context_xa; inspect dmesg or syslog for IRQ/process context lock contention messages after device initialization.

What your security team should do

• Prioritize kernel updates on systems exposing Intel VPU devices.
• Monitor for lockdep deadlock reports mentioning context_xa.
• Test updated kernels in environments using accel/ivpu before broad deployment.