CVE-2026-23438

What it actually does

NULL pointer dereference in mvpp2_bm_switch_buffers when priv->cm3_base is NULL and global_tx_fc guard is missing, triggered by buffer pool mode switch on MTU change crossing jumbo threshold, resulting in kernel panic via readl on address 0.

Why it matters to the business

Local users can trigger kernel crashes causing system reboots, service interruption, and potential loss of in-flight network data on Marvell mvpp2-equipped devices; low exploitability limits widespread impact but requires urgent attention on affected Linux deployments.

How an attack unfolds

A local attacker invokes dev_set_mtu with a value crossing the jumbo threshold on an mvpp2 interface lacking CM3 SRAM in device tree; this reaches mvpp2_bm_switch_buffers without the global_tx_fc check, dereferences NULL cm3_base through mvpp2_cm3_read, and panics the kernel.

How to fix it

Apply the upstream fix that adds priv->global_tx_fc guards around mvpp2_bm_pool_update_priv_fc calls inside mvpp2_bm_switch_buffers; rebuild and deploy the patched kernel; alternatively ensure CM3 SRAM is always present in device tree for mvpp2 nodes.

How to confirm the fix worked

Confirm the guard condition exists in mvpp2_bm_switch_buffers source; test by performing MTU changes across jumbo threshold on hardware without CM3 SRAM and verify no NULL dereference occurs; monitor kernel logs for absence of the reported call trace.

Typical attack path

1. Gain local shell or user context on affected Linux system
2. Identify mvpp2 network interface
3. Execute ip link set dev <if> mtu <jumbo-value>
4. Trigger kernel NULL dereference and panic

How to detect it

Search kernel logs and dmesg for the exact oops signature including readl+0x0, mvpp2_cm3_read, mvpp2_bm_pool_update_priv_fc, mvpp2_bm_switch_buffers, and mvpp2_change_mtu; correlate with recent MTU change events via audit or netlink logs.

• Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
• mvpp2_bm_pool_update_priv_fc+0x94/0xd8
• mvpp2_bm_switch_buffers.isra.0+0x80/0x1c0
• mvpp2_change_mtu+0x140/0x380

What your security team should do

• Patch Linux kernel to include the global_tx_fc guard immediately on all mvpp2 systems
• Restrict local user ability to change MTU on affected interfaces until patched
• Audit device trees for presence of CM3 SRAM entry on cp11x platforms
• Monitor EPSS trend and kernel mailing list for backports