CVE-2026-53216

What it actually does

This is a Linux kernel memory-corruption flaw in the Marvell PPv2 Ethernet driver XDP receive path. The driver can back received packets with buffers smaller than PAGE_SIZE, but it incorrectly advertises the XDP frame size as PAGE_SIZE. XDP helpers such as bpf_xdp_adjust_tail() use that advertised size to decide whether packet tail growth is safe. On affected systems, an XDP program may be allowed to extend packet data beyond the real RX buffer, causing out-of-bounds memory writes, kernel memory corruption, crashes, or potentially privilege escalation depending on system configuration and exploit reliability.

Why it matters to the business

Systems using affected Linux kernels with Marvell PPv2 networking and XDP enabled may be exposed to kernel instability or compromise. The most likely operational impact is network-device crashes, kernel panics, packet-processing disruption, or appliance outages. Exploitation is not currently known to be widespread, EPSS is low, and the issue is not in CISA KEV, but kernel memory-corruption bugs in network paths should still be prioritized for exposed edge, embedded, router, firewall, storage, and appliance-like systems because successful exploitation can affect the entire host.

How an attack unfolds

An attacker first needs a system running an affected Linux kernel on hardware using the mvpp2 network driver. The vulnerable path is most relevant when XDP is enabled on the affected interface and an XDP/eBPF program calls helpers that can grow packet tailroom, such as bpf_xdp_adjust_tail(). In many environments, loading or changing such a program requires elevated local privileges such as CAP_BPF or CAP_NET_ADMIN, so exploitation may require prior local foothold or control over a privileged packet-processing component. Once the vulnerable XDP program is active, crafted network packets received through the mvpp2 interface can drive the XDP path where the kernel believes the packet buffer is PAGE_SIZE even though the actual backing buffer may be smaller. The helper permits tail growth past the true allocation, corrupting adjacent kernel memory or causing later skb tailroom validation failures. A practical attack may result in denial of service through kernel panic; more advanced exploitation could attempt to shape the corruption for kernel-level code execution or privilege escalation.

How to fix it

Upgrade to a Linux kernel that includes the mvpp2 fix which initializes the XDP buffer frame size from the backing BM pool fragment size rather than PAGE_SIZE. If vendor kernel packages are used, apply the relevant distribution, appliance, or device firmware update that incorporates this upstream fix. Where immediate patching is not possible, reduce exposure by disabling XDP on mvpp2-backed interfaces, removing XDP programs that call bpf_xdp_adjust_tail(), restricting who can load eBPF/XDP programs, disabling unprivileged BPF where applicable, and limiting CAP_BPF and CAP_NET_ADMIN to trusted administrative processes only. For high-availability network appliances, test the kernel or firmware update under representative packet-processing workloads before broad deployment.

How to confirm the fix worked

Confirm the running kernel or vendor firmware contains the mvpp2 XDP frame-size fix. Validate by checking vendor advisories, kernel package changelogs, or source code to ensure the mvpp2 XDP buffer initialization uses the BM pool fragment size, commonly represented as bm_pool->frag_size, instead of PAGE_SIZE for the XDP frame size. Identify exposure by checking whether the mvpp2 driver is loaded and whether XDP programs are attached to mvpp2-backed interfaces using tools such as ip link show and bpftool net. After remediation, verify that interfaces still pass traffic, XDP programs load successfully if required, and kernel logs no longer show skb tailroom, KASAN, BUG, panic, or mvpp2-related memory-corruption messages under traffic tests.

Typical attack path

1. Identify a Linux system using the Marvell PPv2 mvpp2 Ethernet driver.
2. Determine whether XDP/eBPF packet processing is attached to an mvpp2-backed network interface.
3. Gain the ability to load, modify, or influence an XDP program that calls bpf_xdp_adjust_tail() or otherwise grows packet tailroom.
4. Send crafted traffic through the affected interface so packets are processed by the vulnerable XDP path.
5. Trigger packet tail growth beyond the real RX buffer size because the driver advertised PAGE_SIZE instead of the actual buffer size.
6. Cause kernel memory corruption, leading to a crash, network outage, or potentially controlled kernel compromise.

How to detect it

There is no single reliable log entry that proves exploitation, because successful kernel memory corruption may leave only a crash or panic. Investigate systems using the mvpp2 driver and XDP for unexplained reboots, kernel panics, network-interface resets, KASAN reports, skb tailroom failures, or BUG messages near times of unusual inbound traffic. Useful sources include kernel logs, persistent journal logs, crash dumps, kdump/vmcore analysis, eBPF/XDP audit records, bpftool state, package update history, and network telemetry. Look for XDP programs attached to mvpp2 interfaces, especially programs using bpf_xdp_adjust_tail(). Treat repeated crashes containing mvpp2, xdp, skb tailroom, or out-of-bounds memory messages as suspicious and preserve crash dumps before reboot cycles overwrite evidence.

• mvpp2
• bpf_xdp_adjust_tail
• skb_over_panic
• skb_put:over
• skb tailroom
• kernel BUG at net/core/skbuff.c
• KASAN: slab-out-of-bounds
• KASAN: use-after-free
• BUG: unable to handle kernel paging request
• Oops:
• Kernel panic - not syncing
• XDP program attached
• xdpdrv
• xdp generic
• bpftool net
• marvell-pp2

What your security team should do

• Inventory Linux systems and appliances using Marvell PPv2 networking or the mvpp2 kernel driver, prioritizing internet-facing, edge, embedded, firewall, router, and storage appliances.
• Patch affected kernels or vendor firmware to a release containing the mvpp2 XDP frame-size correction.
• Identify whether XDP is attached on mvpp2 interfaces; if XDP is not required, disable it until systems are patched.
• Review XDP/eBPF programs for use of bpf_xdp_adjust_tail() and prioritize remediation where tail adjustment is used on affected interfaces.
• Restrict eBPF/XDP loading privileges by limiting CAP_BPF, CAP_NET_ADMIN, and unprivileged BPF access according to platform policy.
• Monitor kernel logs for mvpp2, XDP, skb tailroom, KASAN, BUG, panic, or out-of-bounds memory-corruption messages, especially after unusual traffic spikes.
• Because public exploit maturity is currently reported as none and EPSS is low, prioritize based on hardware exposure and XDP usage rather than treating all Linux systems as equally affected.