CVE-2026-46135

What it actually does

This is a race condition in the Linux kernel NVMe/TCP target implementation. During NVMe/TCP connection initialization, the target may process an Initialization Connection Request while the same queue is already being torn down after the remote host closes the socket. Because queue state transitions were not consistently protected by the queue state lock, the initialization path could move a queue back to LIVE or FAILED after teardown had already moved it to DISCONNECTING. That can allow teardown to run more than once and drop the queue reference a second time, potentially causing use-after-free, double reference release, kernel memory corruption, kernel panic, or, in the worst case, kernel-level code execution. The issue is remotely reachable where the Linux system exposes an NVMe/TCP target service, commonly over TCP port 4420, and does not require authentication according to the assigned network/unauthenticated CVSS characteristics.

Why it matters to the business

Systems acting as NVMe/TCP storage targets may be remotely destabilized by a network attacker, potentially causing storage service outages, host crashes, data path disruption, and loss of availability for workloads that depend on those exported block devices. Because the vulnerable code runs in the kernel, successful exploitation could have severe confidentiality and integrity consequences, although public exploit maturity is currently reported as none, EPSS is low, and the issue is not currently listed in CISA KEV. Organizations with exposed or broadly reachable NVMe/TCP targets should still treat this as high priority because storage infrastructure failures can cascade into application downtime and incident response complexity.

How an attack unfolds

An attacker first identifies a Linux host exposing the NVMe/TCP target service. The attacker opens an NVMe/TCP connection and sends an Initialization Connection Request, then immediately closes or resets the connection to force target-side queue teardown while the request remains buffered for worker processing. If timing aligns, teardown marks the queue as disconnecting and releases a reference, but the later request-handling path updates the same queue state back to a live or failed state without observing the teardown state. A subsequent socket state change or error path can then re-enter teardown and release the same queue reference again. Repeating and timing this sequence can trigger memory safety failure in the kernel, most likely causing a crash or denial of service; with sufficient heap grooming and exploit development, it may provide a path to arbitrary kernel memory corruption.

How to fix it

Upgrade the Linux kernel to a vendor-supported release that includes the fix for the NVMe/TCP target queue state race in nvmet-tcp. No exact fixed version was provided in the input, so use the fixed kernel packages from the relevant Linux distribution or kernel vendor advisory. If immediate patching is not possible, reduce exposure by disabling the NVMe/TCP target functionality where not required, unloading or preventing use of the nvmet_tcp module if operationally safe, restricting access to NVMe/TCP listener ports to trusted storage initiators only, and blocking untrusted network access to TCP/4420 or any configured NVMe/TCP ports. Network segmentation and host firewall rules are important mitigations because the vulnerable path is reachable over the network when the target service is exposed.

How to confirm the fix worked

Confirm the running kernel package/build includes the vendor fix for the nvmet-tcp queue teardown race. Verify whether the system is acting as an NVMe/TCP target by checking loaded modules, kernel configuration, active listeners, and NVMe target configuration. Confirm that TCP/4420 or any custom NVMe/TCP listener is not reachable from untrusted networks. After patching or mitigation, validate that the updated kernel is actually booted, not merely installed. Review dmesg or journal logs for absence of recurring nvmet_tcp-related warnings, KASAN reports, refcount errors, kernel oopses, or panics during NVMe/TCP connection churn tests from authorized test hosts.

Typical attack path

1. Scan for hosts exposing NVMe/TCP target service, commonly TCP/4420.
2. Establish a TCP session to the NVMe/TCP target.
3. Send an NVMe/TCP Initialization Connection Request.
4. Immediately close or reset the connection to trigger target-side queue teardown while initialization processing is still pending.
5. Repeat the connect, initialize, and abrupt disconnect sequence to win the race window.
6. Trigger double queue reference release, use-after-free, or related kernel memory corruption.
7. Cause kernel panic/storage service outage, or attempt further exploitation for kernel-level control if a reliable exploit is developed.

How to detect it

Look for evidence of attempted race triggering against Linux NVMe/TCP targets. Useful sources include kernel logs from dmesg and journald, crash dumps such as kdump/vmcore, SIEM network telemetry, firewall logs, NetFlow, IDS records, and packet captures for NVMe/TCP listener ports. Focus on repeated very short-lived TCP sessions to NVMe/TCP target ports, especially sessions that send initial data and then immediately close or reset. On hosts, search for kernel oops, panic, KASAN, refcount, use-after-free, double-free, or slab corruption messages involving nvmet_tcp code paths. Exploitation may leave no durable file-based artifact if it only causes a crash, so correlation between network connection churn and kernel instability is important. If crash dumps are available, inspect stack traces for nvmet_tcp_handle_icreq, nvmet_tcp_schedule_release_queue, nvmet_tcp_socket_error, or related queue release paths.

• TCP/4420
• nvmet_tcp_handle_icreq
• nvmet_tcp_schedule_release_queue
• nvmet_tcp_socket_error
• nvmet_tcp
• NVMET_TCP_Q_DISCONNECTING
• NVMET_TCP_Q_LIVE
• NVMET_TCP_Q_FAILED
• BUG: KASAN: use-after-free
• BUG: KASAN: slab-use-after-free
• refcount_t: underflow
• refcount_t: addition on 0
• kernel BUG at
• Oops:
• general protection fault
• kernel NULL pointer dereference
• slab corruption
• double free
• use-after-free
• kref_put

What your security team should do

• Prioritize patching Linux systems that operate as NVMe/TCP targets, especially storage nodes reachable from shared, production, or less-trusted networks.
• Inventory exposure by identifying hosts listening on TCP/4420 or configured NVMe/TCP target ports and confirm whether nvmet_tcp is loaded or enabled.
• Restrict NVMe/TCP access to known initiator IP addresses using host firewalls, network ACLs, and storage network segmentation.
• Monitor for repeated short-lived NVMe/TCP connections, abrupt TCP resets, or connection churn against NVMe/TCP target ports.
• Search kernel logs for nvmet_tcp function names, refcount anomalies, KASAN use-after-free reports, and unexplained kernel panics on storage targets.
• If suspicious crashes or memory-corruption logs are found, preserve kernel logs, crash dumps, packet captures, and connection telemetry before rebooting or rebuilding.
• Because this is not currently KEV-listed and EPSS is low, balance urgency against exposure: internet- or broadly reachable NVMe/TCP targets should be handled urgently; isolated, non-target systems are lower priority.