CVE-2026-46304: Linux Kernel Race Condition Vulnerability

CVE-2026-46304 Overview

CVE-2026-46304 is a Linux kernel vulnerability in the NVMe target (nvmet) subsystem. The flaw involves a recursive workqueue flush in nvmet_ctrl_free() that can produce a deadlock condition on the nvmet-wq workqueue. The issue surfaces when nvmet_tcp_release_queue_work() runs on nvmet-wq and drops the final controller reference through nvmet_cq_put(), which triggers nvmet_ctrl_free() and flushes ctrl->async_event_work on the same workqueue. Lockdep detects this as a possible recursive locking condition. The vulnerability affects systems exposing NVMe-over-TCP targets and was resolved upstream through a series of stable kernel patches.

Critical Impact

A recursive flush on the nvmet-wq workqueue during NVMe target controller teardown can deadlock kernel worker threads, disrupting NVMe-over-TCP storage availability.

Affected Products

• Linux kernel NVMe target (nvmet) subsystem
• Linux kernel NVMe-over-TCP transport (nvmet_tcp)
• Stable Linux kernel branches prior to the referenced fix commits

Discovery Timeline

• 2026-06-08 - CVE-2026-46304 published to NVD
• 2026-06-08 - Last updated in NVD database

Technical Details for CVE-2026-46304

Vulnerability Analysis

The defect is a kernel deadlock condition [CWE-667] in the NVMe target subsystem. When an NVMe-over-TCP queue is released, nvmet_tcp_release_queue_work() executes on the nvmet-wq workqueue. During that work item, nvmet_cq_put() may drop the final completion queue reference, which in turn calls nvmet_ctrl_put() and nvmet_ctrl_free(). The teardown path inside nvmet_ctrl_free() calls flush_work(&ctrl->async_event_work), but async_event_work was previously queued on the same nvmet-wq workqueue by nvmet_add_async_event(). Flushing a work item on the same workqueue that is currently executing the caller produces a recursive lock acquisition on the workqueue completion lock.

Root Cause

The root cause is unsafe nesting of workqueue operations. The controller teardown logic synchronously flushes a work item using flush_work() from within a work item already running on the same workqueue. Lockdep flags this as a recursive locking scenario on (wq_completion)nvmet-wq, indicating the two acquisitions of the same workqueue completion lock can deadlock under contention.

Attack Vector

The condition is triggered through normal NVMe target lifecycle events, specifically controller release on the TCP transport. A local privileged operator configuring or tearing down NVMe-over-TCP targets, or remote NVMe initiators repeatedly connecting and disconnecting against an exposed target, can drive the code path. Successful triggering stalls nvmet-wq worker threads and disrupts the storage target's availability. The issue is reproducible with blktests nvme/003 as shown in the upstream report.

The upstream fix restructures controller teardown so that async_event_work is not flushed from a context running on nvmet-wq. See the kernel commits 551f445, 781f47d, 8d66ba8, 9a4d722, a696fbb, aade8ab, ae5b0ca, and ee6e20c for the exact code changes.

Detection Methods for CVE-2026-46304

Indicators of Compromise

• Kernel log entries containing WARNING: possible recursive locking detected referencing (wq_completion)nvmet-wq.
• Stuck kworker/ threads with nvmet_tcp_release_queue_work in the workqueue trace.
• NVMe-over-TCP initiators reporting timeouts or hangs when disconnecting from a target.

Detection Strategies

• Monitor dmesg and journald for lockdep warnings mentioning nvmet-wq, nvmet_ctrl_free, or flush_work from NVMe target code paths.
• Track kernel version inventory against the fix commits listed in the Linux stable tree references to identify unpatched hosts.
• Correlate NVMe target connection churn with kworker thread stalls in performance telemetry.

Monitoring Recommendations

• Forward kernel logs from NVMe target servers to a centralized logging or SIEM platform for warning pattern matching.
• Alert on hung_task detector messages associated with NVMe target workqueues.
• Track NVMe subsystem connect and disconnect events on hosts running nvmet_tcp to baseline normal teardown behavior.

How to Mitigate CVE-2026-46304

Immediate Actions Required

• Inventory all Linux hosts running the NVMe target subsystem with the nvmet and nvmet_tcp modules loaded.
• Apply the latest stable kernel updates from your distribution that include the upstream fix commits.
• Restrict network access to NVMe-over-TCP target ports (default TCP/4420) to trusted initiator networks only.

Patch Information

The fix is committed to the upstream Linux stable tree across multiple branches. Reference commits include 551f445a56a1, 781f47d641432c26c19625b2cdd7f40825097592, 8d66ba89480ff098a58d79003a505f383aa4e920, 9a4d7222c0955b221e38bb66d10e6bccb672c8a1, a696fbbd5240b4ac9b166f7bd4c550882ff543f1, aade8abd8b868b6ffa9697aadaea28ec7f65bee6, ae5b0cad163833e10b271e9becc05d81dae56e5f, and ee6e20c4bc9eae542a0954a368449532383169d4. Consult your Linux distribution's security advisories for backported builds.

Workarounds

• Unload the nvmet_tcp and nvmet kernel modules on systems that do not require NVMe target functionality.
• Avoid frequent NVMe-over-TCP controller teardown patterns on unpatched hosts until updates are deployed.
• Segment NVMe target traffic onto isolated storage networks to limit exposure of the affected code path.

# Verify whether nvmet modules are loaded and identify exposed targets
lsmod | grep -E '^nvmet(_tcp)?'
ss -tlnp | grep ':4420'

# Unload modules if NVMe target is not required
sudo modprobe -r nvmet_tcp
sudo modprobe -r nvmet