CVE-2026-53217: Linux kernel · net: mvpp2: sync RX data at the hardware packet offset
Affects Linux kernelSource CVE Database V5
Not known to be exploited · CVSS 8.6 High · fixed in e302206ad84a407a7e5f3f6fe767ff5efaace689 : patch Linux kernel soon.
Data as of 26 Oct 2026, 13:47 UTC
- EPSS
- 0.3% chance of exploitation in 30 days – higher than 32% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- CISA SSVC
- Exploitation
- No evidence of active exploitation and no public proof of concept
- Automatable
- Attackers can reliably automate steps 1–4 of the kill chain
- Technical impact
- Limited control over the software or limited information exposure
CISA SSVC assessment, 2026-10-16.
- Patch
- Available – fixed in e302206ad84a407a7e5f3f6fe767ff5efaace689, bede0f481b9137d73d1cf64309cbe4b94818a5d6, a13199fa224e9f776f4005d5037df03aa9ea8f37 +5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:LExploitation evidence
Disclosed: evidence found.
CVE published 25 Jun 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Upgrade to a fixed release listed under Affected software.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
Description
In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: sync RX data at the hardware packet offset mvpp2 programs the RX queue packet offset, so hardware writes received data at dma_addr + MVPP2_SKB_HEADROOM. The current CPU sync starts at dma_addr and only covers rx_bytes + MVPP2_MH_SIZE bytes, which syncs the unused headroom and misses the same number of bytes at the packet tail. On non-coherent DMA systems this can leave the CPU reading stale cache contents for the end of the received frame. Use dma_sync_single_range_for_cpu() with MVPP2_SKB_HEADROOM as the range offset so the sync covers the Marvell header and packet data actually written by hardware.
References
- git.kernel.org/stable/c/60412bdd1b2576659eac23a23d2d9ff96228a643 (opens in a new tab)
- git.kernel.org/stable/c/19f8bc139e9b149d1e5bf75ae761d1bb8dd3e7d8 (opens in a new tab)
- git.kernel.org/stable/c/a3ad9b5767c89531fc7dae951b51b0933dcf7051 (opens in a new tab)
- git.kernel.org/stable/c/bede0f481b9137d73d1cf64309cbe4b94818a5d6 (opens in a new tab)
- git.kernel.org/stable/c/23548007b3c66d628fc7d6b80d1e23be04ea10d9 (opens in a new tab)
- git.kernel.org/stable/c/a13199fa224e9f776f4005d5037df03aa9ea8f37 (opens in a new tab)
- git.kernel.org/stable/c/e302206ad84a407a7e5f3f6fe767ff5efaace689 (opens in a new tab)
- git.kernel.org/stable/c/180235600934bef6add3be637c296d6cf3272e67 (opens in a new tab)