CVE-2026-23438

In the Linux kernel, the following vulnerability has been resolved:

net: mvpp2: guard flow control update with global_tx_fc in buffer switching

mvpp2_bm_switch_buffers() unconditionally calls

mvpp2_bm_pool_update_priv_fc() when switching between per-cpu and

shared buffer pool modes. This function programs CM3 flow control

registers via mvpp2_cm3_read()/mvpp2_cm3_write(), which dereference

priv->cm3_base without any NULL check.

When the CM3 SRAM resource is not present in the device tree (the

third reg entry added by commit 60523583b07c ("dts: marvell: add CM3

SRAM memory to cp11x ethernet device tree")), priv->cm3_base remains

NULL and priv->global_tx_fc is false. Any operation that triggers

mvpp2_bm_switch_buffers(), for example an MTU change that crosses

the jumbo frame threshold, will crash:

Unable to handle kernel NULL pointer dereference at

virtual address 0000000000000000

Mem abort info:

ESR = 0x0000000096000006

EC = 0x25: DABT (current EL), IL = 32 bits

pc : readl+0x0/0x18

lr : mvpp2_cm3_read.isra.0+0x14/0x20

Call trace:

readl+0x0/0x18

mvpp2_bm_pool_update_fc+0x40/0x12c

mvpp2_bm_pool_update_priv_fc+0x94/0xd8

mvpp2_bm_switch_buffers.isra.0+0x80/0x1c0

mvpp2_change_mtu+0x140/0x380

__dev_set_mtu+0x1c/0x38

dev_set_mtu_ext+0x78/0x118

dev_set_mtu+0x48/0xa8

dev_ifsioc+0x21c/0x43c

dev_ioctl+0x2d8/0x42c

sock_ioctl+0x314/0x378

Every other flow control call site in the driver already guards

hardware access with either priv->global_tx_fc or port->tx_fc.

mvpp2_bm_switch_buffers() is the only place that omits this check.

Add the missing priv->global_tx_fc guard to both the disable and

re-enable calls in mvpp2_bm_switch_buffers(), consistent with the

rest of the driver.