CVE-2024-35819

What it actually does

The cgr_lock spinlock could sleep under PREEMPT_RT when smp_call_function_single invoked the callback from hard IRQ context during link state changes, violating atomic context rules and enabling a race condition in the qbman driver.

Why it matters to the business

Kernel instability or crashes can occur on systems using DPAA networking hardware during routine link up/down events, leading to network outages and requiring reboots in affected Linux deployments.

How an attack unfolds

An attacker triggers repeated network link state transitions on a DPAA interface; each transition calls qman_update_cgr_safe which invokes smp_call_function_single while the non-raw cgr_lock is held, exposing the sleeping lock bug in IRQ context.

How to fix it

Update the Linux kernel to a version containing commit 0adb32858b0bddf4ada5f364a84ed60b196dbcda which changes cgr_lock to a raw spinlock.

How to confirm the fix worked

Verify the running kernel source contains the raw_spinlock_t declaration for cgr_lock and confirm the fix commit is present in the git log; test link up/down events under PREEMPT_RT without observing warnings or crashes.

Typical attack path

1. Identify a target Linux system using the qbman/DPAA driver
2. Cause or wait for network link state changes (up/down events)
3. Trigger the smp_call_function path while cgr_lock is acquired
4. Induce sleep in hard IRQ context leading to kernel panic or deadlock

How to detect it

Search kernel logs for spinlock warnings or BUGs mentioning cgr_lock or smp_call_function in IRQ context; review dmesg and audit logs around network interface events for evidence of prior crashes.

What your security team should do

• Prioritize kernel upgrades on all systems using fsl/qbman or DPAA networking
• Monitor for kernel oops or warnings related to spinlock usage in IRQ context
• Apply the fix commit immediately on PREEMPT_RT configurations
• Review downstream distributions for backported patches