CVE-2026-98272: net: mvpp2: prevent buffer overflow in page_pool allocation
Telemetry drift only. No threshold crossed and no authority ruling changed.
CVE record, CISA KEV and EPSS as of 2026-10-18.
CVEs like this one computed, by meaning
What to do now held facts and links
- Upgrade to the fixed version for your release line, or later: 5.10.271; 5.15.222; 6.1.189; 6.6.158; 6.12.112; 6.18.54; 7.2.8 CVE record
- Record your decision, dated and frozen with today's evidence: patch by a date · mitigated by a compensating control · deferred · accepted the risk · not affected
- Check your version against the ranges this record publishes.
What it is stated by the CNA
In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: prevent buffer overflow in page_pool allocation The per‑processor buffering scheme is supported only if the number of pools (nrxqs * 2) does not exceed MVPP2_BM_MAX_POOLS (8). This is already checked in mvpp2_probe() during the initial activation of percpu_pools. However, mvpp2_change_mtu() may later call mvpp2_bm_switch_buffers(priv, true) without this check, which can lead to an out-of-bounds access in the priv->page_pool array in mvpp2_bm_init(). The array is sized to hold MVPP2_PORT_MAX_RXQ entries, and mvpp2_get_nrxqs() may return exactly that value. The per-CPU scheme then doubles it to nrxqs * 2, exceeding the array bounds. Check that the hardware version is MVPP22 or newer and that the number of pools (nrxqs * 2) does not exceed MVPP2_BM_MAX_POOLS before switching to per-CPU mode. …
- weakness
- Not named by the CNA.
- affected
- Linux
- versions
- No affected-version range in held sources.
- fixed in
- 5.10.271; 5.15.222; 6.1.189; 6.6.158; 6.12.112; 6.18.54; 7.2.8
- assigned by
- Linux
- published
- 2026-10-06
check us git.kernel.org git.kernel.org git.kernel.org git.kernel.org
Exploit code held, dated
- exploit code
- None held in the PoC-in-GitHub feed. A public repository changes this brief.
Outside the record researched, cited
This section reads the record's references and adds cited findings from outside it. It needs an account. Everything above is held facts and is complete without it.
What would change this brief held, dated
- CISA KEV
- Not listed in the catalogue we hold. A listing changes this brief.
- exploit probability
- 0.00 on 2026-10-06 (FIRST's EPSS, a probability and not evidence of exploitation). Next band line: 10% (0.10). Crossing a line changes this brief.
- fix
- Held: 5.10.271; 5.15.222; 6.1.189; 6.6.158; 6.12.112; 6.18.54; 7.2.8. A newer fix from the CNA or OSV changes this brief.
How to check this
Every value above is held with two dates: when it was true upstream (as_of) and when we recorded it (tx_from). Re-derive the exploit probability as it stood on any date:
SELECT value, source, source_version, as_of, tx_from
FROM volatile_valid_as_of('CVE-2026-98272', '2026-10-31T23:59:59.999999Z', now());