A race condition in the Linux kernel's Marvell mvpp2 network driver can corrupt the parser TCAM/SRAM state and silently deny network availability by dropping all incoming unicast traffic — a bug tracked as CVE-2025-22060 that was fixed in upstream kernel trees by serializing access to the parser’s hardware tables.
If you need verbatim upstream commit text or an exact list of cherry-picked commit IDs for a specific stable kernel (e.g., stable-v6.6.87 backport IDs), I recommend pulling the git.kernel.org stable branch directly or using your distro’s security-commit-list; vendor advisories list the corresponding package updates and backport references. The distribution advisories cited above are the canonical place to find patched package names and versions for your platform.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background
What is mvpp2 and where it runs
The mvpp2 driver implements the packet processing and Ethernet controller interface for Marvell PPv2 family devices found in a range of Armada and other Marvell SoCs used in embedded routers, switches, and network appliances. The driver exposes a header parser (TCAM + SRAM) and classifier that decide how packets are forwarded and which RX queues receive traffic. That header parser is implemented in kernel drivers under drivers/net/ethernet/marvell/mvpp2 and has long included debug and initialization code for the TCAM/SRAM structures.Why TCAM/SRAM matter
TCAM (Ternary Content-Addressable Memory) and associated SRAM entries are hardware tables used by the packet parser/classifier to match MAC/VLAN/IP headers and make forwarding/classification decisions at wire speed. On mvpp2 hardware, those tables are accessed indirectly: software writes an index register to select a row and then reads or writes data registers to modify that row. Because the hardware API uses an index register rather than direct per-row addresses, callers must treat multi-register read/write sequences as atomic operations — otherwise a concurrent writer can change the index mid-sequence and cause writes to land in the wrong row. The kernel-side “shadow” SRAM array caches the parser state to track which hardware rows are used; if that shadow state is corrupted by racing updates, multiple cores can allocate the same hardware row (a TOCTOU problem) and the classifier may become misconfigured.The vulnerability in plain terms
- The root cause was concurrent access to the parser TCAM/SRAM and the driver’s shadow SRAM without proper locking.
- The problematic scenario observed by the maintainers occurred when mvpp2_set_rx_mode() ran concurrently on two CPUs; this code path interacts with promiscuous/unicast filtering entries. The concurrency could corrupt the MVPP2_PE_MAC_UC_PROMISCUOUS entry, effectively telling the hardware to drop unicast traffic.
Technical analysis — how the fix works
What the upstream patch changes
Upstream maintainers addressed the issue by adding a dedicated prs_spinlock and taking that lock around accesses that read or modify PRS (parser) TCAM/SRAM rows and the driver’s shadow array. The patch introduces:- A new spinlock in struct mvpp2 (prs_spinlock).
- lockdep assertions in helper routines that assume the PRS lock is held.
- wrapper functions that take/release the spinlock (e.g., converting mvpp2_prs_init_from_hw into an internal __mvpp2_prs_init_from_hw plus a locking wrapper).
- Replacements of previously-unprotected calls with locked variants, and use of spin_lock_bh where appropriate to protect from bottom-half contexts.
Why this prevents memory corruption and the TOCTOU window
Because the hardware uses an index register, a write to that index followed by several data register writes is only safe when nothing else can change the index in the interim. The new spinlock enforces that only one CPU at a time can run those multi-register sequences. The fix also protects the shadow array lookups so that two cores do not pick the same free slot (the classic TOCTOU race). This is the correct kernel-side pattern for protecting hardware that requires multi-step register sequences.Exploitability and impact
What an attacker can do
The vulnerability is a local/adjacent denial-of-service vector: by causing concurrent execution of RX-mode changes (or other code paths that modify parser entries), an attacker can trigger corruption of a parser entry and force the classifier to drop unicast packets. In practice this could result in a sustained denial of service for affected ports until the driver is reset or the system is updated. Multiple vendors and vulnerability databases classify the impact as a loss of availability.CVSS and vendor severity
Different vendors and trackers assigned slightly different scores based on their assessments of attack vector and prerequisites. NVD documents a CVSS v3.1 score of 4.7 (Medium) while Red Hat/Amazon listings and some distro advisories have recorded somewhat higher base scores (around the mid‑5 range) reflecting an AV:L (adjacent) attack vector and an availability impact. In short, this is a medium-severity kernel bug with a clear availability impact for affected hardware.Who is affected
The affected component is the mvpp2 driver inside the Linux kernel; distributions shipping kernels that include the vulnerable code paths (CNA metadata shows affected ranges starting from older kernel versions up through early 6.x stable releases before the backport) should consider themselves vulnerable on systems that actually use Marvell PPv2 hardware. Several enterprise distributions (Ubuntu, Debian, SUSE, SLES variants, Amazon Linux derivatives) published advisories and fixed packages. If you do not run hardware using Marvell’s PPv2 packet processor, this bug is not relevant to you.Detection — how to spot the problem in the field
There is no single universal "Exploit Completed" signature shipped with the kernel; operators must use a combination of driver stats, kernel logs, and functional checks.- Watch for unexplained increases in classifier-related drop counters and sudden unicast traffic failures on affected ports. The vulnerability description explicitly mentions the driver-observed rx_classifier_drops counter as an indicator that the classifier was dropping unicast due to a corrupted entry. If that counter grows in tandem with operator actions (e.g., toggling RX modes, enabling promiscuous mode), investigate further.
- Use ethtool -S <ifname> and driver debugfs if available to inspect detailed hardware statistics. Many mvpp2 driver builds expose debugfs entries and specific stats that can help identify parser/classifier drops; consult your distribution’s kernel build and the driver debugfs documentation for exact paths.
- Monitor network health from the host and upstream: sudden inability to establish new connections or persistent one-way traffic loss (ingress packets not delivered to the kernel) on impacted interfaces is a strong red flag.
- Check kernel logs (dmesg/journal) for driver warnings or repeated reinitialization messages around mvpp2 or PRS initialization; in some vendor builds, the fix adds lockdep assertions which may generate diagnostic messages if locking assumptions fail during debug builds.
Mitigation — patches, workarounds, and operational guidance
Apply vendor patches (recommended, immediate)
The only correct fix is to install vendor-supplied kernel updates that include the upstream mvpp2 fixes. Major distributions have released patched kernel packages in response to CVE-2025-22060; search your distro advisories and install the kernel updates appropriate for your release:- Ubuntu published an advisory with fixes in their kernel packages. Updating via apt and rebooting into the patched kernel is recommended.
- SUSE and SLES released updated kernel-default packages and livepatch/livepatch-equivalent fixes depending on your edition; SLES kernel-default fixed versions were published for downstream images. Enterprise SLES/SUSE customers should consume the vendor errata.
- Debian, Amazon Linux, and other distributors listed the issue in their trackers and provided package-level fixes or guidance on which kernels are affected/fixed. Check the Debian security tracker and distribution advisories for exact package names and fixed versions before upgrading.
Temporary mitigations when immediate patching isn’t possible
If you cannot install the kernel update immediately, consider short-term mitigations:- Avoid concurrent invocations of network mode changes on systems running mvpp2 hardware. In practice this means not toggling promiscuous/unicast filtering from multiple management processes at the same time and avoiding scripted bulk changes that touch RX-mode on many interfaces concurrently.
- Limit the number of CPUs executing mvpp2_set_rx_mode–style operations by restricting management tools to a single control CPU (set CPU affinity for management processes) while you plan a patching window. This is a brittle stopgap and may not be practical on most systems. Vendor advisories have suggested locking or serialization as a temporary measure.
- Isolate vulnerable appliances from untrusted networks if they cannot be patched promptly — put them behind a firewall or within a management VLAN so that local or adjacent attackers cannot trick the system into concurrent mode changes.
Long-term operational fixes
- Incorporate kernel update validation into your device lifecycle and configuration management: embedded network appliances and SoC-based devices often lag in kernel updates; ensure these devices are tracked and updated on a schedule.
- For vendors integrating kernel trees into appliances, ensure the mvpp2 test coverage includes concurrent rx_mode toggles and TOCTOU stress tests to catch regressions early.
Risk assessment for enterprises and embedded vendors
- Embedded network devices and appliances using Marvell PPv2 hardware should be considered high-priority for patching. These devices often run in critical network paths (edge routers, access switches, IoT gateways), and a misconfigured classifier that drops unicast traffic can cause service outages for entire subnets.
- Cloud and server environments are less likely to be affected unless they intentionally run Marvell PPv2 NICs or SoCs in their infrastructure. Still, any vendor appliance (e.g., network appliances sold with custom Linux kernels) that includes the vulnerable driver must be updated. Distribution advisories (Ubuntu, SUSE, Debian, Amazon) indicate which package versions include the fix.
- The exploitability is limited by the requirement to cause concurrent parser modifications (the attack vector is adjacent/local), so remote attackers without access to the local management plane are less likely to trigger it. However, in multi-tenant or exposed management networks an adjacent attacker could engineer conditions to trigger the issue. The upshot: treat this as an availability risk for any device that uses mvpp2 hardware and runs an affected kernel.
For developers and maintainers: code-level takeaways
- Hardware register APIs that require multi-step sequences (index register + data registers) must be guarded by locks that enforce atomicity across the entire sequence.
- Cached (“shadow”) copies that represent hardware state must be protected from concurrent modification; otherwise TOCTOU races will let two cores allocate or update the same hardware resource.
- The correct kernel pattern is a small, well-documented spinlock (or other locking primitive) that covers both the hardware register sequence and the shadow bookkeeping; tests should include concurrency stress under heavy CPU counts. The upstream mvpp2 patch implements precisely this pattern.
What I checked and what remains partially unverifiable
During this research I cross-referenced the NVD advisory and multiple distribution advisories (Ubuntu, SUSE, Debian, Amazon) and inspected an upstream patch summary and diffs as presented through vendor/stable-cherry-pick mail archives; those resources consistently describe the root cause (concurrent TCAM/SRAM access) and the fix (add a PRS spinlock and serialize accesses). The upstream commit references kernel.org commit IDs; a kernel.org raw commit fetch was referenced by several advisories but was not directly retrieved from kernel.org in this investigative session. The code diffs and patch summary captured in the public stable/stable-v6.x emails and the mvpp2 driver sources served via code browsers gave sufficient detail to confirm the technical reasoning and the nature of the fix. Where a direct upstream git commit URL was referenced by advisories, I used those advisories and the available patch diffs as confirmatory evidence.If you need verbatim upstream commit text or an exact list of cherry-picked commit IDs for a specific stable kernel (e.g., stable-v6.6.87 backport IDs), I recommend pulling the git.kernel.org stable branch directly or using your distro’s security-commit-list; vendor advisories list the corresponding package updates and backport references. The distribution advisories cited above are the canonical place to find patched package names and versions for your platform.
Action checklist (fast-reference)
- Inventory: identify systems that use Marvell PPv2/mvpp2 hardware. If unsure, check lspci/lsmod/firmware/hardware documentation on appliances and boards.
- Patch: apply the vendor-supplied kernel updates for your distribution (Ubuntu, Debian, SUSE, SLES, Amazon Linux, etc.) and reboot into the patched kernel. Confirm package names and versions per your distro advisory.
- Validate: after patching, verify that rx_classifier_drops no longer grows unexpectedly and that unicast traffic functions as expected (use ethtool -S, driver debugfs, and network functional tests).
- Short-term controls: if you cannot patch immediately, avoid concurrent RX mode toggles and isolate vulnerable devices behind trusted management networks.
- Long-term: add mvpp2 concurrency tests to CI for embedded Linux builds and track kernel security advisories for stable backports.
Conclusion
CVE-2025-22060 is a textbook example of a concurrency problem in kernel drivers: a hardware register interface that requires multi-step sequences was accessed without adequate serialization, producing a TOCTOU window that corrupted parser state and caused a practical denial of service. The fix — adding a dedicated parser-spinlock and taking it for all PRS hardware/shadow accesses — is straightforward and has been applied in upstream and distribution kernels. Operators should prioritize installing vendor kernel updates on systems that use Marvell PPv2 hardware, validate network functionality post‑patch, and adopt simple concurrency-aware testing in device integration pipelines to reduce the chance of similar regressions in the future.Source: MSRC Security Update Guide - Microsoft Security Response Center
