CVE-2026-31557: Linux Kernel Race Condition Vulnerability

CVE-2026-31557 Overview

A race condition vulnerability exists in the Linux kernel's NVMe Target (nvmet) subsystem that can lead to recursive workqueue locking and system deadlocks. The vulnerability occurs when nvmet_ctrl_free() flushes ctrl->async_event_work while running on the same nvmet-wq workqueue, causing the workqueue completion lock to be acquired twice by the same worker thread.

Critical Impact
This vulnerability can cause kernel deadlocks and system hangs on Linux systems utilizing NVMe over Fabrics (NVMeoF) target functionality, particularly those using RDMA transport. Remote attackers may be able to trigger denial of service conditions through carefully timed NVMe disconnection events.

Affected Products

Linux Kernel versions 5.18 and later
Linux Kernel version 7.0-rc1 through 7.0-rc7
Systems using NVMe Target (nvmet) subsystem with RDMA transport

Discovery Timeline

2026-04-24 - CVE-2026-31557 published to NVD
2026-04-27 - Last updated in NVD database

Technical Details for CVE-2026-31557

Vulnerability Analysis

This vulnerability is a race condition in the Linux kernel's NVMe Target subsystem that leads to recursive locking of workqueue completion locks. The flaw exists in how asynchronous event work is scheduled and flushed during controller teardown operations.

When an NVMe target controller is freed via nvmet_ctrl_free(), it attempts to flush any pending async event work. However, if this free operation itself runs on the nvmet-wq workqueue (which commonly occurs during RDMA connection manager disconnect handling), the flush operation attempts to acquire the same workqueue completion lock that the current worker already holds.

The lockdep subsystem detects this as a potential deadlock scenario, as demonstrated in the warning message showing kworker attempting to acquire (wq_completion)nvmet-wq while already holding that same lock from process_one_work().

Root Cause

The root cause is an architectural design flaw where both async event work and queue release work are scheduled on the same workqueue (nvmet-wq). The call chain proceeds as follows:

RDMA CM handler queues release_work on nvmet-wq
Worker processes release work, acquiring the workqueue completion lock
Release work calls through to nvmet_ctrl_free()
nvmet_ctrl_free() calls flush_work() on async_event_work
Flush operation attempts to acquire the same workqueue completion lock

This violates the workqueue locking invariant that a worker cannot wait for completion of work on its own workqueue.

Attack Vector

The vulnerability can be triggered through network-accessible NVMe over Fabrics interfaces. An attacker with network access to an NVMeoF target can initiate connection and disconnection sequences that trigger the vulnerable code path through the RDMA Connection Manager.

The attack flow involves:

Establishing an NVMeoF RDMA connection to the target
Triggering async events that queue work on nvmet-wq
Initiating a disconnect that triggers the release_work path
The combination of pending async work and release work processing on the same workqueue triggers the recursive lock

The vulnerability requires no authentication to the NVMeoF target to trigger, as the disconnect handling occurs during connection teardown regardless of authentication state.

Detection Methods for CVE-2026-31557

Indicators of Compromise

Kernel log messages containing "WARNING: possible recursive locking detected" with nvmet-wq references
System hangs or unresponsive behavior on NVMeoF target servers
Kernel panic or soft lockup messages referencing nvmet_ctrl_free or __flush_work
Hung task warnings in kernel logs involving kworker threads on nvmet-wq

Detection Strategies

Monitor kernel logs for lockdep warnings mentioning (wq_completion)nvmet-wq recursive locking
Configure kernel crash dump analysis to capture deadlock conditions in NVMeoF environments
Implement monitoring for hung kworker threads associated with nvmet workqueues
Deploy syslog rules to alert on nvmet-related kernel warnings and errors

Monitoring Recommendations

Enable kernel lockdep debugging on non-production systems to proactively detect locking issues
Monitor NVMeoF target connection/disconnection rates for anomalous patterns
Set up automated alerting for kernel soft lockup and hung task detector warnings
Track system availability metrics on NVMeoF target servers to detect availability impacts

How to Mitigate CVE-2026-31557

Immediate Actions Required

Update affected Linux kernel to a patched version as soon as available
Consider limiting network access to NVMeoF target ports to trusted hosts only
Monitor systems for signs of exploitation while awaiting patch deployment
Prepare for potential service disruption and have recovery procedures ready

Patch Information

The Linux kernel developers have resolved this vulnerability by moving async event work to a dedicated workqueue (nvmet-aen-wq) separate from the main nvmet-wq. This architectural change prevents the recursive locking scenario by ensuring that flush operations for async event work never occur within a worker on the same workqueue.

Patches are available through the following kernel git commits:

Workarounds

Restrict network access to NVMeoF target services using firewall rules to limit exposure
Consider temporarily disabling NVMeoF RDMA target services if not critical for operations
Implement network segmentation to isolate NVMeoF traffic from untrusted networks
Deploy intrusion detection systems to monitor for suspicious NVMeoF connection patterns

bash

# Example: Restrict NVMeoF RDMA port access using iptables
# Default NVMeoF RDMA port is typically 4420
iptables -A INPUT -p tcp --dport 4420 -s trusted_network/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 4420 -j DROP