Live › vulnerability › CVE-2026-98931
Go to dashboardWhen a SPI-NAND device is declared with nand-no-ecc-engine in the device tree, the kernel's SPI-NAND driver dereferences a NULL pointer during probe and oopses. The sources describe a crash on probe, not code execution or data exposure.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Systems running a Linux kernel with the MTD SPI-NAND driver that boot with a device tree declaring nand-no-ecc-engine on a SPI-NAND chip. Systems without such a device tree entry are not hit by this path.
No product ranges from the sources yet.
Unknown from the sources.
Unknown from the sources.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
In the Linux kernel, the following vulnerability has been resolved:
mtd: spinand: fix NULL pointer dereference with no ECC engine
When "nand-no-ecc-engine" is set in DT, nanddev_get_ecc_engine() takes the NAND_ECC_ENGINE_TYPE_NONE path and returns success while leaving nand->ecc.engine NULL. The SPI-NAND code nevertheless dereferences it unconditionally to test for a pipelined engine, so probing such a device oopses immediately.
Rather than open-coding the test three times, add a nand_ecc_is_pipelined() helper to the NAND core that folds the NULL check into the integration comparison, and use it everywhere. Future callers then cannot reintroduce the problem.
This page as .md · .json · in your agent: get_signal("CVE-2026-98931")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.