CVE-2026-46304

What it actually does

This flaw affects the Linux kernel NVMe target over TCP code path. During NVMe/TCP queue teardown, nvmet_tcp_release_queue_work can run on the nvmet-wq workqueue and drop the final controller reference. That can invoke nvmet_ctrl_free(), which attempts to flush ctrl->async_event_work on the same nvmet-wq. Flushing work from the same workqueue can create a recursive workqueue dependency and potential deadlock. The practical technical impact is loss of availability of the affected NVMe target path, potentially causing hung kernel worker threads, stalled NVMe target cleanup, degraded storage service behavior, or system instability under trigger conditions involving NVMe/TCP connection creation and teardown.

Why it matters to the business

Systems acting as Linux NVMe-over-TCP storage targets may become unstable or unavailable if the vulnerable teardown path is triggered. For organizations using NVMe/TCP for storage services, this can disrupt storage access, cause application outages, require node reboots, and affect service-level commitments. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no public exploit maturity reported, but the CVSS availability impact is high and exposed NVMe/TCP targets should still be prioritized because storage-plane outages can have broad operational consequences.

How an attack unfolds

An attacker who can reach an exposed NVMe/TCP target service would attempt to trigger repeated NVMe/TCP controller, discovery, or queue setup and teardown activity. By causing a queue release while asynchronous controller event work is pending on the same nvmet workqueue, the attacker may cause the kernel to enter the vulnerable teardown sequence where nvmet_ctrl_free() flushes work already associated with nvmet-wq. On vulnerable kernels, this can lead to a recursive workqueue dependency and potential deadlock, resulting in denial of service for the NVMe/TCP target path or broader kernel instability. No confirmed in-the-wild exploitation or named threat actor activity is provided for this vulnerability.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the NVMe target change described as avoiding recursive nvmet-wq flush in nvmet_ctrl_free. Because no affected product list or exact fixed versions were provided, use the patched kernel packages supplied by the relevant Linux distribution, appliance vendor, cloud image provider, or kernel maintainer. Prioritize systems that load or use nvmet and nvmet_tcp modules or expose NVMe/TCP target services. If immediate patching is not possible, reduce exposure by disabling NVMe/TCP target functionality where not required, unloading nvmet_tcp if safe to do so, restricting access to NVMe/TCP ports to trusted initiators only, and applying firewall or network ACL controls around TCP port 4420 and any custom NVMe/TCP service ports. Avoid exposing NVMe/TCP target services directly to untrusted networks.

How to confirm the fix worked

Confirm the running kernel includes the vendor fix by checking the installed kernel package changelog, vendor advisory, or upstream commit history for the nvmet fix that avoids recursive nvmet-wq flush in nvmet_ctrl_free. Verify that hosts using NVMe/TCP have been rebooted into the fixed kernel, not merely had packages installed. Check whether nvmet_tcp is loaded with lsmod or equivalent tooling, and verify active NVMe/TCP listeners with ss, netstat, or service configuration review. For exposure validation, confirm TCP port 4420 or any configured NVMe/TCP target port is not reachable from untrusted networks. In test environments, controlled NVMe/TCP connect/disconnect regression testing should no longer produce kernel lockdep warnings mentioning recursive locking, nvmet-wq, or nvmet_tcp_release_queue_work.

Typical attack path

1. Identify a Linux host exposing NVMe/TCP target functionality, commonly on TCP port 4420 or another configured NVMe/TCP port.
2. Connect to the NVMe/TCP discovery or target service and initiate controller/session activity.
3. Trigger rapid or repeated disconnects, queue teardown, or controller removal conditions.
4. Attempt to align teardown with pending asynchronous NVMe target event work on the nvmet-wq workqueue.
5. Cause the vulnerable recursive workqueue flush condition, potentially hanging kernel workqueue processing or degrading NVMe/TCP target availability.
6. Repeat the activity to sustain or amplify storage service disruption.

How to detect it

Look for evidence of exploitation or attempted triggering in kernel logs, system journals, storage service telemetry, and network logs around NVMe/TCP activity. Useful sources include dmesg, /var/log/kern.log, /var/log/messages, journalctl -k, audit logs for kernel module loading, firewall logs, and network telemetry for TCP connections to NVMe/TCP ports such as 4420. Focus on bursts of NVMe/TCP discovery, controller creation, controller removal, disconnects, and repeated connections from the same source followed by kernel warnings, workqueue stalls, blocked tasks, or storage target unavailability. Because no public exploit-specific payload or actor tooling is provided, detection should rely on behavioral correlation: remote NVMe/TCP connection churn plus kernel messages referencing nvmet-wq, nvmet_tcp_release_queue_work, recursive locking, deadlock, or blocked kworkers. Review logs for the period since publication and especially around any storage outage or unexplained reboot.

• WARNING: possible recursive locking detected
• *** DEADLOCK ***
• (wq_completion)nvmet-wq
• Workqueue: nvmet-wq nvmet_tcp_release_queue_work
• nvmet_tcp_release_queue_work
• nvmet_ctrl_free
• flush_work(&ctrl->async_event_work)
• nvmet_add_async_event
• queue_work(nvmet_wq, &ctrl->async_event_work)
• nvmet_tcp: enabling port
• nvmet: Created discovery controller
• Removing ctrl: NQN
• nqn.2014-08.org.nvmexpress.discovery
• TCP/4420

What your security team should do

• Inventory Linux systems that provide NVMe-over-TCP target services or have nvmet/nvmet_tcp modules enabled.
• Patch and reboot exposed NVMe/TCP target systems to a kernel version containing the fix from the operating system or appliance vendor.
• Restrict NVMe/TCP access to trusted initiator networks only; block TCP port 4420 and custom NVMe/TCP ports from untrusted networks.
• Review kernel logs for historical signs of recursive locking, nvmet-wq deadlocks, or NVMe/TCP controller teardown instability.
• Increase monitoring on storage target nodes for kernel worker hangs, blocked tasks, NVMe/TCP disconnect storms, and storage latency or availability degradation.
• If patching must be delayed, disable NVMe/TCP target functionality where business operations permit.
• Track vendor advisories because exact fixed package versions vary by distribution and kernel branch.