Cloudanix VulnDB

CVE-2026-98153

Medium · 5.5

CVSS

5.5

EPSS

0.1%

Published

Sep 25, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing flaw in how the Linux kernel sets up certain high-speed storage devices could let a logged-in user crash the system, though the issue is hard to trigger and no widespread attacks are known.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition in nvme_query_fdp_info() allows concurrent unsynchronized writes to a namespace head's nr_plids/plids arrays when multiple paths scan the same namespace, potentially corrupting FDP registration state.

Why it matters to the business

May cause kernel instability or crashes on Linux systems using NVMe devices with Flexible Data Placement, though public exploitability remains very low 28 days after disclosure with no observed campaigns.

How an attack unfolds

A local attacker with access to trigger multiple I/O paths against the same NVMe namespace can force concurrent calls to nvme_query_fdp_info(), racing to populate the shared plids structures before the one-time initialization in nvme_alloc_ns_head() was introduced.

How to fix it

Upgrade the Linux kernel to a version containing the fix that relocates FDP initialization into nvme_alloc_ns_head(); rebuild and reboot affected systems; monitor vendor backports for distribution kernels.

How to confirm the fix worked

Verify the presence of the upstream commit moving initialization work to nvme_alloc_ns_head(); confirm single initialization path via code review or kernel debug logs; test concurrent namespace registration under load.

Typical attack path

  1. Obtain local user access on a Linux system with NVMe FDP-capable hardware
  2. Trigger concurrent namespace scans via multiple paths or processes
  3. Cause nvme_query_fdp_info() to race on head->nr_plids/head->plids
  4. Trigger kernel memory corruption or null dereference leading to denial of service

How to detect it

Search kernel logs for oops, warnings, or panics referencing nvme_query_fdp_info or plids array access; inspect for concurrent namespace registration patterns in dmesg or trace events around FDP initialization.

What your security team should do

  • Prioritize kernel updates for any systems exposing NVMe FDP namespaces
  • Apply updates within standard patch windows given low EPSS and absence from KEV
  • Review NVMe driver usage in container or virtualized workloads for exposure
  • Monitor kernel oops and panic logs for FDP-related races until patched

The record

In the Linux kernel, the following vulnerability has been resolved: nvme: fix racy access to FDP placement id array nvme_query_fdp_info() is called per-path and therefore prone to races. It populates head->nr_plids/head->plids for fdp registration. But nothing protects that pair from concurrent access - two paths scanning the same namespace can race to populate it. Avoid the race by moving this initialization work to nvme_alloc_ns_head() which is called once per shared namespace.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities