Cloudanix VulnDB

CVE-2026-90411

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in the Linux kernel's storage driver can waste memory each time certain high-speed disk connections fail to start, which over time might slow systems or cause them to stop responding.

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

What it actually does

A DMA mapping for cmd_iu is performed without a matching unmap when rsp_iu mapping subsequently fails in __nvme_fc_init_request, and the lack of an .exit_request callback on init failure leaves the mapping permanently leaked while the request remains in an inconsistent state.

Why it matters to the business

Systems using NVMe over Fibre Channel storage may experience gradual exhaustion of DMA resources or I/O queue memory over repeated initialization failures, leading to reduced storage performance or outages; the issue has low exploitability and no known active campaigns.

How an attack unfolds

An attacker with local access or the ability to induce repeated NVMe-FC request initialization errors (for example through malformed fabric responses or driver stress) can trigger the leak path; because blk-mq does not clean up on failure, each occurrence permanently consumes kernel DMA mappings until reboot.

How to fix it

Apply the upstream kernel patch that adds an error path to unmap cmd_iu and return without setting FCPOP_STATE_IDLE; rebuild and deploy the fixed kernel on all affected NVMe-FC hosts; monitor for driver updates in distribution kernels.

How to confirm the fix worked

Confirm the presence of the error-path jump and unmap call in __nvme_fc_init_request; exercise init failure paths in a test environment and verify no DMA mappings remain allocated after failure returns; check kernel version or commit history for the fix.

Typical attack path

  1. Trigger conditions that cause rsp_iu DMA mapping to fail during nvme-fc request initialization
  2. Allow the function to return without unmapping the prior cmd_iu allocation
  3. Repeat the failure pattern to accumulate leaked mappings
  4. Observe resource pressure or I/O failures once mappings are exhausted

How to detect it

Search kernel logs for repeated nvme-fc init failures or DMA mapping warnings; inspect /proc or crash dumps for leaked DMA handles associated with nvme-fc requests; correlate with blk-mq request allocation failures on Fibre Channel devices.

What your security team should do

  • Prioritize patching NVMe-FC hosts that handle production storage traffic
  • Review kernel changelogs for the exact nvme-fc fix and backport if distribution packages lag
  • Add monitoring for DMA allocation warnings or I/O queue exhaustion on Fibre Channel initiators

The record

In the Linux kernel, the following vulnerability has been resolved: nvme-fc: unmap cmd_iu DMA on rsp_iu mapping failure in init_request __nvme_fc_init_request() maps cmd_iu and then rsp_iu for DMA. If the rsp_iu mapping fails, the original code only recorded the error and fell through: it left the already-mapped cmd_iu unmapped and still marked the op as FCPOP_STATE_IDLE before returning. Since blk-mq does not call .exit_request() when .init_request() fails, the cmd_iu mapping is leaked for every op whose rsp_iu mapping fails. Jump to an error path on rsp_iu mapping failure that unmaps cmd_iu and returns the error without marking the op idle, so it stays in the FCPOP_STATE_UNINIT state set by the initial memset().

Affected packages

Ecosystem Package Introduced Fixed