Cloudanix VulnDB

CVE-2026-98931

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A configuration issue with certain memory chips can make the system crash right when it starts up.

Exploitation
Local Privilege
Attacker needs
High Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

NULL pointer dereference in SPI-NAND device probing when nanddev_get_ecc_engine returns success but leaves nand->ecc.engine as NULL due to nand-no-ecc-engine DT property, causing unconditional dereference and kernel oops.

Why it matters to the business

Kernel crash during boot or device initialization on systems using affected SPI-NAND configurations, resulting in system unavailability, failed device bring-up, and potential data inaccessibility until patched.

How an attack unfolds

An attacker with ability to influence device tree configuration or trigger NAND device probing (such as via physical access, compromised bootloader, or kernel module load) sets nand-no-ecc-engine, causing the unconditional dereference during mtd spinand initialization and immediate kernel panic.

How to fix it

Apply the upstream fix introducing nand_ecc_is_pipelined helper with NULL check, or upgrade to a Linux kernel version containing the resolution for this mtd spinand NULL dereference.

How to confirm the fix worked

Confirm kernel source contains nand_ecc_is_pipelined helper usage in place of direct engine checks; test device probe with nand-no-ecc-engine DT property succeeds without oops.

Typical attack path

  1. Configure device tree with nand-no-ecc-engine property for target SPI-NAND device
  2. Trigger kernel module load or device probe for mtd spinand subsystem
  3. nanddev_get_ecc_engine takes NONE path leaving engine NULL
  4. SPI-NAND code dereferences engine pointer without check
  5. Kernel oops/panic occurs immediately

How to detect it

Review kernel logs (dmesg, syslog) for spinand or mtd NULL pointer dereference oops during device probe; search for device tree entries containing nand-no-ecc-engine on affected systems.

What your security team should do

  • Prioritize kernel update on all embedded and server systems using SPI-NAND flash within 30 days given recent publication
  • Audit device trees for nand-no-ecc-engine usage and verify ECC configuration
  • Monitor kernel logs for mtd or spinand oops during boot after changes

The record

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.

Affected packages

Ecosystem Package Introduced Fixed