CVE-2026-46304: Linux Kernel NVMe Target Work Queue Deadlock Vulnerability

Technical summary

CVE-2026-46304 is a deadlock vulnerability in the Linux kernel's nvmet subsystem stemming from recursive work queue locking. The vulnerability exists in the nvmet_ctrl_free() function, which attempts to flush ctrl->async_event_work on the nvmet-wq work queue. However, nvmet_ctrl_free() can be invoked from nvmet_tcp_release_queue_work(), which is already executing on the same nvmet-wq. The call chain originates when nvmet_tcp_release_queue() drops the final controller reference via nvmet_cq_put(), triggering nvmet_cq_destroy() and ultimately nvmet_ctrl_put(). When nvmet_ctrl_free() calls flush_work() on a work item scheduled on the queue from which it is currently being executed, lockdep detects and warns of the recursive locking pattern. The kernel logs show the warning triggered during NVMe discovery controller removal, with the locking scenario clearly documented in the CVE description.

Business impact

This vulnerability affects organizations deploying NVMe-over-Fabrics or NVMe-over-TCP storage services, particularly those using Linux kernel-based NVMe target implementations for virtual storage, network block devices, or fabric-connected storage arrays. When triggered, the deadlock can freeze the nvmet work queue, rendering NVMe target services unresponsive and preventing client connections or disconnections. In production environments providing network storage or block device services, this can cascade into application outages and data access interruptions. Cloud providers, storage appliance vendors, and enterprises running containerized storage solutions face operational disruption risk.

Affected systems

The vulnerability affects all Linux kernel versions containing the vulnerable nvmet code path. Systems running kernels with the nvmet-tcp module enabled are at risk, particularly those configured to provide NVMe target functionality. The issue is triggered by controller lifecycle operations, meaning any workload that creates and destroys NVMe controllers over TCP can trigger the condition. This includes NVMe discovery controller setup and teardown, which occurs during normal client connection/disconnection sequences.

Exploitability

This vulnerability is not exploitable remotely for privilege escalation or data theft; it is a denial-of-service condition triggered through normal NVMe protocol operations. An attacker with network access to an exposed NVMe-over-TCP target can trigger controller creation and removal sequences to repeatedly invoke the deadlock condition. However, the vulnerability is equally likely to occur during legitimate client disconnection, making it primarily a reliability issue. The low barrier to triggering (standard NVMe client disconnect) increases risk in multi-tenant or untrusted network environments.

Remediation

The kernel patch resolves the issue by avoiding the flush_work() call on async_event_work when nvmet_ctrl_free() is invoked from a context already holding the nvmet-wq lock. The fix modifies the controller teardown path to defer or skip the synchronous flush when the controller reference is dropped from within the work queue itself. Verify the specific patch version against the Linux kernel stable and mainline repositories, as the fix version depends on kernel series (6.x, 5.15.x, etc.).

Patch guidance

Apply the latest kernel update from your distribution that includes the nvmet deadlock resolution. For distributions with kernel version tracking: verify that your running kernel incorporates the patch that modifies nvmet_ctrl_free() to avoid recursive work queue flushes. Typical distributions will release updates for stable kernel versions (6.1.x, 5.15.x longterm support lines) within their standard security update channels. Reboot systems after patching to ensure the new kernel is active. No configuration changes are required; the fix is transparent to NVMe target service operation.

Detection guidance

Monitor kernel logs for the lockdep warning: 'WARNING: possible recursive locking detected' with context pointing to ((wq_completion)nvmet-wq) and nvmet_tcp_release_queue_work in the call trace. Systems may also exhibit nvmet work queue hangs visible through 'hung_task_timeout_secs' warnings or unresponsive NVMe targets. In live monitoring, watch for NVMe target clients unable to disconnect cleanly or controller creation/removal taking excessive time. Analyze dmesg output during NVMe controller lifecycle transitions to identify the specific warning pattern. Kernel instrumentation tools (trace-cmd, perf) can capture the problematic call sequence if detailed investigation is required.

Why prioritize this

Assign HIGH priority to patching systems providing NVMe target services or running nvmet_tcp, particularly in production environments serving client storage traffic. The CVSS 7.5 score reflects high availability impact and low attack complexity, though not confidentiality or integrity loss. Organizations with NVMe-over-Fabrics deployments, cloud storage platforms, or containerized storage systems should prioritize this patch. Non-production systems and those without active NVMe target services can follow standard update cycles.

Risk score, explained

The CVSS 3.1 score of 7.5 (HIGH) is justified by the denial-of-service impact (high availability loss through work queue deadlock), combined with network accessibility (AV:N) and lack of authentication requirements (PR:N, UI:N). The vulnerability is not remotely exploitable for data exfiltration or integrity compromise, limiting the scope to availability. The score appropriately reflects the operational impact to storage services while acknowledging the absence of confidentiality or integrity violations.

Frequently asked questions