CVE-2026-98931 in Linux
Summary
by MITRE • 10/23/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/23/2026
The Linux kernel's Memory Technology Device subsystem contains a critical flaw within the SPI-NAND driver implementation related to error correction code engine initialization. This vulnerability manifests as a null pointer dereference when a device tree configuration explicitly specifies that no ECC engine should be used by setting the nand-no-ecc-engine property. The root cause lies in the behavior of the nanddev_get_ecc_engine function, which correctly handles this specific configuration path by returning success while intentionally leaving the ecc.engine structure member as NULL to indicate the absence of a hardware or software correction mechanism. However, the SPI-NAND driver code fails to account for this valid state and proceeds to dereference the engine pointer unconditionally during device probing operations. This unconditional access occurs when attempting to determine if the ECC engine supports pipelined operations, leading directly to a kernel panic or system crash upon initialization of such devices.
From a technical perspective, this issue represents a classic failure in defensive programming where assumptions about data structure validity are not validated against all possible configuration states defined by the device tree. The vulnerability allows for immediate denial of service during the boot process if an affected SPI-NAND flash chip is detected with the no-ECC flag set. This prevents the system from mounting root filesystems or accessing storage media that rely on this specific driver, effectively rendering systems using these configurations inoperable until patched. The flaw highlights a gap between the core NAND subsystem's abstraction layer and the specific implementation details of SPI-NAND drivers regarding how they interact with optional hardware features like ECC engines.
The remediation strategy involves refactoring the code to eliminate redundant null checks scattered throughout the driver logic. By introducing a centralized helper function named nand_ecc_is_pipelined within the NAND core, developers can encapsulate the necessary NULL pointer validation alongside the pipelining capability check. This approach ensures that any future callers or modifications to the SPI-NAND driver will automatically inherit this safety mechanism, thereby preventing regression of the vulnerability. The change promotes code reuse and enforces consistent handling of optional ECC engine states across different NAND device types within the kernel ecosystem.
In terms of industry standards classification, this vulnerability aligns with CWE-476 which describes a NULL pointer dereference error. Such errors occur when software attempts to use a pointer that has not been initialized or has been explicitly set to null without proper validation before access. The operational impact falls under availability violations as defined by the CIA triad, specifically causing system instability and preventing normal operation during device initialization phases. Security analysts tracking kernel vulnerabilities should note this pattern of improper input handling from device tree configurations leading to memory corruption events in low-level storage drivers.
Mitigation for organizations running affected Linux kernels involves applying upstream kernel patches that include the nand_ecc_is_pipelined helper function integration. System administrators managing embedded systems or industrial controllers utilizing SPI-NAND flash should verify their bootloader and device tree source files do not inadvertently trigger this code path unless absolutely necessary, though relying on software ECC is often preferred for data integrity in many applications. Regular kernel updates are essential to maintain resilience against such low-level memory safety issues that can compromise system stability without requiring external network access or user interaction.