CVE-2024-35806

What it actually does

Missing IRQ disable when acquiring cgr_lock in qbman code paths allows deadlock with smp_call_function_single callbacks that already disable IRQs.

Why it matters to the business

Potential kernel deadlocks or system hangs on affected PowerPC hardware can cause unplanned downtime and service interruption in environments using Freescale QBMAN.

How an attack unfolds

An attacker with local code execution triggers concurrent cgr_lock acquisitions from process and IPI contexts; the missing IRQ disable on one path leads to deadlock when the other path executes under disabled IRQs.

How to fix it

Update torvalds/linux to commit c470abd4fde40ea6a0846a2beab642a578c0b8cd or later; rebuild and deploy the patched kernel on all affected systems.

How to confirm the fix worked

Verify the running kernel contains commit c470abd4fde40ea6a0846a2beab642a578c0b8cd via git log or kernel version string; test cgr_lock paths under concurrent load to confirm absence of deadlock.

Typical attack path

1. Obtain local execution on affected Linux system
2. Trigger qbman cgr operations from multiple CPUs simultaneously
3. Force one path to take cgr_lock without IRQ disable while smp_call_function_single executes
4. Induce deadlock resulting in system unresponsiveness

How to detect it

Review kernel logs for deadlock warnings or hangs involving qbman or cgr_lock; inspect crash dumps for lock acquisition traces without IRQ state checks.

What your security team should do

• Apply the referenced kernel commit immediately on all systems using qbman
• Prioritize patching in environments with multi-CPU PowerPC hardware
• Monitor for kernel deadlock reports post-deployment