CVE-2024-35837

What it actually does

Stale BM pool register values from a prior kernel instance persist across kexec reboot and are not cleared before mvpp2 buffer management pool initialization, resulting in invalid state and kernel panic.

Why it matters to the business

Systems relying on kexec for fast reboot or crash recovery experience unexpected kernel panics, leading to unplanned downtime and degraded availability on affected networking hardware.

How an attack unfolds

An attacker with the ability to trigger a kexec reboot on a vulnerable system (or who can force a kernel crash that leads to kexec) can cause the mvpp2 driver to read stale BM pool register contents, resulting in a crash during early driver initialization.

How to fix it

Upgrade the Linux kernel to a version containing commit 83f99138bf3b396f761600ab488054396fb5768f or later; apply the upstream fix that clears BM pool registers before initialization.

How to confirm the fix worked

Confirm the running kernel contains commit 83f99138bf3b396f761600ab488054396fb5768f; verify BM pool registers are explicitly zeroed in the mvpp2 probe path via source inspection or dynamic tracing.

Typical attack path

1. Gain ability to initiate kexec or force a kernel panic that triggers kexec
2. Trigger reboot into new kernel image
3. mvpp2 driver loads and reads uncleared BM pool registers
4. Driver encounters invalid state and panics the kernel

How to detect it

Review kernel boot logs and panic traces for mvpp2-related initialization failures immediately after a kexec reboot; examine dmesg for register values or BM pool errors on affected devices.

What your security team should do

• Prioritize kernel upgrade on any system using mvpp2 and kexec workflows
• Add kexec reboot testing to regression suites for affected hardware
• Monitor for kernel panics referencing mvpp2 during boot after kexec