Cloudanix VulnDB

CVE-2026-98272

None

CVSS

—

EPSS

0.2%

Published

Oct 6, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A flaw in certain network cards used in Linux servers can let an attacker who is already on the machine crash the system or gain higher privileges by changing a network setting.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Buffer Overflow
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Out-of-bounds write in the page_pool array inside mvpp2_bm_init when mvpp2_change_mtu triggers per-CPU buffer switching without validating that nrxqs*2 stays below MVPP2_BM_MAX_POOLS.

Why it matters to the business

Kernel memory corruption on systems using the mvpp2 Ethernet driver can cause crashes, denial of service, or potential local privilege escalation during routine MTU changes.

How an attack unfolds

An attacker with local access changes the MTU on an mvpp2 interface, causing mvpp2_change_mtu to invoke mvpp2_bm_switch_buffers without the pool-count check; this leads to an out-of-bounds access in the page_pool array sized only for MVPP2_PORT_MAX_RXQ entries.

How to fix it

Update to a kernel containing the fix that adds hardware-version and pool-count checks before enabling per-CPU mode in mvpp2_change_mtu; backport the check to any downstream tree still missing it.

How to confirm the fix worked

Confirm the presence of the pool-count guard in mvpp2_change_mtu and that MVPP22+ hardware paths enforce the MVPP2_BM_MAX_POOLS limit; run kernel self-tests exercising MTU changes on mvpp2 devices.

Typical attack path

  1. Obtain local shell on a system with mvpp2 hardware
  2. Issue ifconfig or ip link set mtu command on the affected interface
  3. Trigger mvpp2_change_mtu path that calls mvpp2_bm_switch_buffers
  4. Exceed MVPP2_BM_MAX_POOLS bounds and corrupt kernel memory

How to detect it

Search kernel logs for oops or panic messages containing mvpp2_bm_init, mvpp2_change_mtu, or page_pool array references immediately following MTU change events; inspect audit logs for MTU modifications on mvpp2 interfaces.

What your security team should do

  • Prioritize kernel updates for any host exposing mvpp2 interfaces
  • Restrict local unprivileged users from changing MTU on mvpp2 devices until patched
  • Monitor for kernel oops or page faults referencing mvpp2_bm_init after MTU modifications

The record

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. Found by Linux Verification Center (linuxtesting.org) with SVACE.

Affected packages

Ecosystem Package Introduced Fixed