CVE-2026-98272: net: mvpp2: prevent buffer overflow in page_pool allocation
In the Linux kernel, the following vulnerability has been resolved:
net: mvpp2: prevent buffer overflow in pagepool allocation
The per‑processor buffering scheme is supported only if the number of pools (nrxqs 2) does not exceed MVPP2BMMAXPOOLS (8). This is already checked in mvpp2probe() during the initial activation of percpupools.
However, mvpp2changemtu() may later call mvpp2bmswitchbuffers(priv, true) without this check, which can lead to an out-of-bounds access in the priv->pagepool array in mvpp2bminit(). The array is sized to hold MVPP2PORTMAXRXQ entries, and mvpp2getnrxqs() 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 MVPP2BMMAXPOOLS before switching to per-CPU mode.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Before activating the per-CPU buffering scheme, verify that the hardware version is MVPP22 or newer.
- Compensating control
Before switching to per-CPU mode, enforce that the number of buffer pools (nrxqs * 2) does not exceed MVPP2_BM_MAX_POOLS (8).
Event History
Frequently Asked Questions
Which systems are exposed to the out-of-bounds access?
Exposure requires the Linux kernel mvpp2 driver, hardware version MVPP22 or newer, and a receive-queue configuration where twice the number of receive queues exceeds the maximum of 8 buffer-manager pools. The affected path is reached when switching to per-CPU buffer pools.
Does the initial driver setup prevent this condition?
The initial activation path checks the pool limit before enabling per-CPU pools. However, a later MTU change can switch buffers without that check, allowing the unsafe configuration to reach page-pool initialization.
What can be done if the fix cannot be applied immediately?
Avoid MTU changes that could trigger a switch to per-CPU buffer mode on affected MVPP2 hardware and queue configurations. The supplied fix adds checks for MVPP22-or-newer hardware and ensures that nrxqs multiplied by two does not exceed 8 before switching modes.
How can an administrator identify a potentially affected configuration?
Verify that the system uses the mvpp2 driver on MVPP22-or-newer hardware, then determine the receive queue count. A configuration is potentially affected when nrxqs multiplied by two is greater than 8, particularly if the MTU is changed after initialization.