NULL Pointer Dereference Affecting kernel-docs-html package, versions <6.12.0-160000.35.1
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-SLES1600-KERNELDOCSHTML-17354325
- published17 Jun 2026
- disclosed15 Jun 2026
Introduced: 15 Jun 2026
NewCVE-2026-23438 (opens in a new tab)How to fix?
Upgrade SLES:16.0.0 kernel-docs-html to version 6.12.0-160000.35.1 or higher.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-docs-html package and not the kernel-docs-html package as distributed by SLES.
See How to fix? for SLES:16.0.0 relevant fixed versions and status.
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.
References
- https://www.suse.com/security/cve/CVE-2026-23438.html
- https://bugzilla.suse.com/1261619
- https://git.kernel.org/stable/c/0cfcd31f98fc608dc9406bff3fee3a9dd364d014
- https://git.kernel.org/stable/c/7bd20f4b3ef3044dc55acd5b8ef748a70d29d03f
- https://git.kernel.org/stable/c/7df2b50cae1a76cbb90b294f3edb61e3e10bf2e9
- https://git.kernel.org/stable/c/8a63baadf08453f66eb582fdb6dd234f72024723
- https://git.kernel.org/stable/c/8baced53a35fc9710f80d6ca016a2c418dc3231f
- https://git.kernel.org/stable/c/da089f74a993f846685067b14158cb41b879ff29
- https://git.kernel.org/stable/c/ff0c54f088f7ab91dbbf47cf8244460f99122750