CVE-2026-53217

What it actually does

This flaw affects the Linux kernel Marvell PPv2 Ethernet driver, commonly referenced as mvpp2. On systems with non-coherent DMA, the driver synchronized the wrong receive-buffer range before the CPU processed inbound packets. Because the hardware writes received data at an offset into the DMA buffer, but the driver synchronized from the beginning of the buffer, the synchronization covered unused headroom and failed to synchronize an equivalent number of bytes at the end of the received frame. As a result, the CPU may read stale cache contents for the tail of a received packet. The practical impact is packet data corruption and potential exposure or reuse of stale data previously present in CPU cache, depending on platform behavior and how the received frame is later processed.

Why it matters to the business

Organizations running affected Linux kernels on hardware using the Marvell PPv2 Ethernet driver may experience unreliable network packet handling, including corrupted traffic, intermittent application/network failures, or unintended exposure of stale data under specific hardware conditions. The vulnerability is not known to be exploited, is not listed in CISA KEV, has low EPSS likelihood, and requires specific affected hardware and non-coherent DMA behavior, so broad internet-scale exploitation is unlikely; however, appliances, embedded systems, routers, storage devices, and network-facing Linux systems using this driver should still be updated during normal kernel maintenance because network data integrity issues can be difficult to diagnose operationally.

How an attack unfolds

An attacker would need network reachability to an affected system or device using the mvpp2 driver on a non-coherent DMA platform. The attacker sends crafted or carefully sized Ethernet frames to the affected interface. The Marvell PPv2 hardware writes the packet data into the receive buffer at the configured packet offset, but the driver synchronizes the cache starting at the base DMA address rather than at the hardware write offset. This leaves the tail end of the actual received frame unsynchronized. When the Linux networking stack processes the packet, the CPU may read stale cached bytes instead of the bytes most recently written by the network hardware. Depending on packet size, cache state, and subsequent handling, this can cause corrupted packet interpretation or potential leakage/reuse of stale data within packet-processing paths. There is currently no public indication of mature exploitation or known threat actor use.

How to fix it

Apply a Linux kernel update that includes the mvpp2 RX DMA synchronization fix. The corrected implementation synchronizes the DMA range actually written by hardware by using the receive packet offset, specifically synchronizing from MVPP2_SKB_HEADROOM so the Marvell header and packet data are covered. If vendor fixed package versions are not available, upgrade to the latest kernel provided by the operating system, appliance, or hardware vendor that includes the upstream fix for the mvpp2 driver. Where immediate patching is not possible, reduce exposure by limiting untrusted network access to affected interfaces, placing affected systems behind trusted network boundaries, disabling unused interfaces using mvpp2, or using alternative network hardware/drivers where feasible. Because this is a kernel driver issue, mitigation through application-layer controls is limited.

How to confirm the fix worked

Confirm exposure by checking whether the system uses the mvpp2 driver and Marvell PPv2 Ethernet hardware, then verify the running kernel includes the fix. On Linux systems, review loaded modules and driver bindings with commands such as lsmod, ethtool -i <interface>, lspci, platform device listings, or /sys/class/net/<interface>/device/driver where applicable. Validate remediation by confirming the installed kernel package version matches a vendor release containing the fix, or by checking the kernel source/patch history for the mvpp2 change that replaces the incorrect RX synchronization with dma_sync_single_range_for_cpu() using MVPP2_SKB_HEADROOM as the range offset. After updating, reboot into the fixed kernel and verify the active kernel with uname -a or package inventory tooling. Functional validation can include network receive testing under load and monitoring for packet corruption, checksum anomalies, or unexplained receive-side errors, but absence of such symptoms does not prove the system was never vulnerable.

Typical attack path

1. Identify a Linux-based target or appliance using Marvell PPv2 Ethernet hardware and the mvpp2 kernel driver.
2. Confirm or infer that the platform uses non-coherent DMA behavior where explicit cache synchronization is required.
3. Send network traffic to the affected interface, potentially using frame sizes or layouts that maximize impact at the tail of the receive buffer.
4. Trigger the driver to synchronize the incorrect DMA range during receive processing.
5. Cause the CPU/network stack to process stale cached bytes at the end of received frames, resulting in packet corruption or possible stale data exposure depending on system behavior.

How to detect it

There are no reliable, vulnerability-specific indicators that prove prior exploitation. The issue occurs at the kernel driver and DMA cache-synchronization layer, so exploitation may appear only as malformed or corrupted network traffic rather than explicit logs. For exposure assessment, collect hardware and driver inventory from endpoint management, kernel package data, ethtool output, and system boot logs showing mvpp2 driver use. For possible historical abuse or impact, review network telemetry, packet captures, IDS logs, and application logs for unexplained packet corruption, malformed protocol messages, checksum validation failures, abrupt connection resets, or anomalies concentrated on systems using the mvpp2 driver. Kernel logs may show interface resets, RX errors, checksum errors, or driver-related warnings, but these are nonspecific and can have many causes. If sensitive environments are involved, compare traffic captures taken on both sides of an affected device to identify receive-side data inconsistencies or unexpected trailing bytes in frames. No named threat actors or ransomware campaigns are currently associated with this vulnerability.

What your security team should do

• Inventory Linux systems, embedded devices, network appliances, and storage platforms that use Marvell PPv2 Ethernet hardware or the mvpp2 driver.
• Prioritize patching affected internet-facing or untrusted-network-facing systems, even though current exploitation likelihood is low and the vulnerability is not in CISA KEV.
• Obtain fixed kernels or firmware from the operating system, appliance, or hardware vendor and schedule reboot-based deployment where required.
• For systems that cannot be updated immediately, restrict untrusted traffic to affected interfaces and disable unused mvpp2-backed network ports.
• Add vulnerability-management checks for kernel versions and driver exposure rather than relying only on application scanners, because this issue resides in a kernel network driver.
• Monitor vendor advisories for exact fixed package versions if they are not yet published for the relevant distribution or appliance.
• After patching, verify that systems are actually booted into the fixed kernel, not merely that the package is installed.