CVE-2025-22060

What it actually does

Race condition in the mvpp2 parser allows concurrent TCAM/SRAM index register writes and shadow SRAM updates across CPUs, causing writes to span multiple rows or duplicate row allocations leading to corrupted classifier entries such as MVPP2_PE_MAC_UC_PROMISCUOUS.

Why it matters to the business

Network traffic can be silently dropped or misclassified on affected systems, disrupting connectivity and requiring emergency kernel updates on production Linux hosts that use the mvpp2 driver.

How an attack unfolds

An attacker with local access triggers concurrent execution of mvpp2_set_rx_mode on multiple CPUs; the non-atomic index configuration and unprotected shadow array cause TOCTOU errors that corrupt hardware parser tables, resulting in all unicast frames being dropped by the classifier.

How to fix it

Apply the kernel patch referenced by commit e3711163d14d02af9005e4cdad30899c565f13fb or upgrade to a fixed kernel build; for listed Red Hat packages update squid to 7:3.5.20-17.el7_9.11 or newer equivalent.

How to confirm the fix worked

Verify the running kernel contains commit e3711163d14d02af9005e4cdad30899c565f13fb, confirm rx_classifier_drops counter remains stable under load, and test concurrent rx mode changes do not produce corruption.

Typical attack path

1. Obtain local code execution on a system using the mvpp2 Ethernet driver
2. Trigger concurrent calls to rx mode configuration functions from multiple CPUs
3. Exploit lack of locking around TCAM index writes and shadow SRAM allocation
4. Corrupt classifier entries causing rx_classifier_drops to rise
5. Deny service for incoming unicast traffic

How to detect it

Inspect kernel logs and network driver statistics for abrupt increases in rx_classifier_drops after concurrent rx mode changes; correlate with process activity that invokes mvpp2_set_rx_mode on multi-CPU systems.

• rx_classifier_drops counter spike
• MVPP2_PE_MAC_UC_PROMISCUOUS corruption
• concurrent mvpp2_set_rx_mode calls from multiple CPUs

What your security team should do

• Prioritize kernel updates on all systems exposing the mvpp2 driver within the published remediation window
• Monitor rx_classifier_drops and system logs for sudden unicast packet loss
• Restrict untrusted local code execution until patches are deployed
• Review downstream dependents and schedule staged rollouts for high-prevalence environments