Cloudanix VulnDB

CVE-2026-23434

High · 7.1

CVSS

7.1

EPSS

0.1%

Published

Apr 3, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A problem in the way the operating system coordinates flash memory operations could let a local user interfere with storage tasks and cause crashes or data problems.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Data Tampering
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

A race condition in the Linux kernel NAND subsystem allows nand_lock() and nand_unlock() to execute without the device lock, permitting concurrent SET_FEATURES PIO commands to conflict with UBI/UBIFS erase/write operations that hold the lock and resulting in cmd_pending errors on the controller.

Why it matters to the business

Systems relying on NAND flash storage may experience unexpected command failures, potential data corruption, or availability loss during background flash management, increasing operational risk for embedded, server, and storage deployments running the affected kernel.

How an attack unfolds

An attacker with local access crafts concurrent NAND area lock/unlock calls alongside ongoing UBI background operations; because the lock/unlock path lacks serialization, the controller sees interleaved low-level commands and fails or corrupts state.

How to fix it

Upgrade the Linux kernel to a version containing the fix that wraps nand_lock() and nand_unlock() with nand_get_device()/nand_release_device() calls; rebuild and deploy the updated kernel across all affected hosts.

How to confirm the fix worked

Inspect kernel source or running binary for the presence of nand_get_device() immediately before chip->ops.lock_area/unlock_area and nand_release_device() immediately after; confirm no concurrent access paths remain unprotected.

Typical attack path

  1. Gain local user or process execution on a Linux system using NAND storage
  2. Trigger or schedule concurrent UBI/UBIFS erase/write activity
  3. Invoke nand_lock() or nand_unlock() paths without holding the device lock
  4. Induce cmd_pending conflict on the NAND controller leading to operation failure or corruption

How to detect it

Review kernel logs for cmd_pending conflicts or NAND controller errors during lock/unlock sequences; correlate with UBI background thread activity; examine source code or kprobes for missing device lock acquisition around area lock calls.

What your security team should do

  • Prioritize kernel upgrade on all systems using raw NAND or UBI/UBIFS within the next patch cycle due to the 206-day disclosure window
  • Restrict local unprivileged access on high-value NAND-based appliances until patched
  • Monitor vendor advisories for exact fixed kernel versions and backports

The record

In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: serialize lock/unlock against other NAND operations nand_lock() and nand_unlock() call into chip->ops.lock_area/unlock_area without holding the NAND device lock. On controllers that implement SET_FEATURES via multiple low-level PIO commands, these can race with concurrent UBI/UBIFS background erase/write operations that hold the device lock, resulting in cmd_pending conflicts on the NAND controller. Add nand_get_device()/nand_release_device() around the lock/unlock operations to serialize them against all other NAND controller access.

Affected packages

Ecosystem Package Introduced Fixed