CVE-2026-46304
Received Received - Intake
Recursive Locking in Linux Kernel NVMe Target

Publication date: 2026-06-08

Last updated on: 2026-06-08

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: nvmet: avoid recursive nvmet-wq flush in nvmet_ctrl_free nvmet_tcp_release_queue_work() runs on nvmet-wq and can drop the final controller reference through nvmet_cq_put(). If that triggers nvmet_ctrl_free(), the teardown path flushes ctrl->async_event_work on the same nvmet-wq. Call chain: nvmet_tcp_schedule_release_queue() kref_put(&queue->kref, nvmet_tcp_release_queue) nvmet_tcp_release_queue() queue_work(nvmet_wq, &queue->release_work) <--- nvmet_wq process_one_work() nvmet_tcp_release_queue_work() nvmet_cq_put(&queue->nvme_cq) nvmet_cq_destroy() nvmet_ctrl_put(cq->ctrl) nvmet_ctrl_free() flush_work(&ctrl->async_event_work) <--- nvmet_wq Previously Scheduled by :- nvmet_add_async_event queue_work(nvmet_wq, &ctrl->async_event_work); This trips lockdep with a possible recursive locking warning. [ 5223.015876] run blktests nvme/003 at 2026-04-07 20:53:55 [ 5223.061801] loop0: detected capacity change from 0 to 2097152 [ 5223.072206] nvmet: adding nsid 1 to subsystem blktests-subsystem-1 [ 5223.088368] nvmet_tcp: enabling port 0 (127.0.0.1:4420) [ 5223.126086] nvmet: Created discovery controller 1 for subsystem nqn.2014-08.org.nvmexpress.discovery for NQN nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349. [ 5223.128453] nvme nvme1: new ctrl: NQN "nqn.2014-08.org.nvmexpress.discovery", addr 127.0.0.1:4420, hostnqn: nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349 [ 5233.199447] nvme nvme1: Removing ctrl: NQN "nqn.2014-08.org.nvmexpress.discovery" [ 5233.227718] ============================================ [ 5233.231283] WARNING: possible recursive locking detected [ 5233.234696] 7.0.0-rc3nvme+ #20 Tainted: G O N [ 5233.238434] -------------------------------------------- [ 5233.241852] kworker/u192:6/2413 is trying to acquire lock: [ 5233.245429] ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90 [ 5233.251438] but task is already holding lock: [ 5233.255254] ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x5cc/0x6e0 [ 5233.261125] other info that might help us debug this: [ 5233.265333] Possible unsafe locking scenario: [ 5233.269217] CPU0 [ 5233.270795] ---- [ 5233.272436] lock((wq_completion)nvmet-wq); [ 5233.275241] lock((wq_completion)nvmet-wq); [ 5233.278020] *** DEADLOCK *** [ 5233.281793] May be due to missing lock nesting notation [ 5233.286195] 3 locks held by kworker/u192:6/2413: [ 5233.289192] #0: ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x5cc/0x6e0 [ 5233.294569] #1: ffffc9000e2a7e40 ((work_completion)(&queue->release_work)){+.+.}-{0:0}, at: process_one_work+0x1c5/0x6e0 [ 5233.300128] #2: ffffffff82d7dc40 (rcu_read_lock){....}-{1:3}, at: __flush_work+0x62/0x530 [ 5233.304290] stack backtrace: [ 5233.306520] CPU: 4 UID: 0 PID: 2413 Comm: kworker/u192:6 Tainted: G O N 7.0.0-rc3nvme+ #20 PREEMPT(full) [ 5233.306524] Tainted: [O]=OOT_MODULE, [N]=TEST [ 5233.306525] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 5233.306527] Workqueue: nvmet-wq nvmet_tcp_release_queue_work [nvmet_tcp] [ 5233.306532] Call Trace: [ 5233.306534] <TASK> [ 5233.306536] dump_stack_lvl+0x73/0xb0 [ 5233.306552] print_deadlock_bug+0x225/0x2f0 [ 5233.306556] __lock_acquire+0x13f0/0x2290 [ 5233.306563] lock_acquire+0xd0/0x300 [ 5233.306565] ? touch_wq_lockdep_map+0x26/0x90 [ 5233.306571] ? __flush_work+0x20b/0x530 [ 5233.306573] ? touch_wq_lockdep_map+0x26/0x90 [ 5233.306577] touch_wq_lockdep_map+0x3b/0x90 [ 5233.306580] ? touch_wq_lockdep_map+0x26/0x90 [ 52 ---truncated---
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-06-08
Last Modified
2026-06-08
Generated
2026-06-09
AI Q&A
2026-06-08
EPSS Evaluated
N/A
NVD
CVE-2026-46304
EUVD
EUVD-2026-35169
Affected Vendors & Products
Showing 2 associated CPEs
Vendor Product Version / Range
linux_kernel nvmet 7.0.0-rc3nvme+
linux linux_kernel 7.0.0-rc3nvme+
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Quick Actions
Instant insights powered by AI
Executive Summary

This vulnerability exists in the Linux kernel's nvmet subsystem, specifically related to the handling of workqueue flushing in the nvmet_ctrl_free function.

The issue arises because the function nvmet_tcp_release_queue_work(), which runs on the nvmet-wq workqueue, can trigger the release of the final controller reference. This leads to nvmet_ctrl_free() being called, which attempts to flush ctrl->async_event_work on the same nvmet-wq workqueue.

This causes a recursive flush of the same workqueue, leading to a possible recursive locking scenario and a deadlock warning detected by the kernel's lock dependency checker (lockdep). Essentially, the workqueue tries to acquire a lock it already holds, which can cause a deadlock.

Impact Analysis

This vulnerability can cause the Linux kernel to detect a possible deadlock situation due to recursive locking in the nvmet subsystem.

The impact includes potential system instability or hangs when the nvmet subsystem is in use, as the kernel workqueue may deadlock while trying to flush work items.

This could affect systems using NVMe target functionality over TCP, potentially leading to degraded performance or system responsiveness issues.

Detection Guidance

This vulnerability manifests as a possible recursive locking warning in the Linux kernel related to the nvmet subsystem. It can be detected by monitoring kernel logs for specific warning messages indicating recursive locking or deadlock scenarios involving the nvmet-wq workqueue.

  • Check kernel logs for warnings similar to: "WARNING: possible recursive locking detected" and messages referencing "nvmet-wq".
  • Use the command: dmesg | grep -i 'nvmet-wq' to filter kernel messages related to the nvmet workqueue.
  • Look for deadlock or lockdep warnings in kernel logs with: dmesg | grep -i 'recursive locking'
Mitigation Strategies

The vulnerability has been resolved in the Linux kernel by avoiding recursive flushing of the nvmet-wq workqueue during controller teardown. Immediate mitigation involves updating the Linux kernel to a version that includes this fix.

  • Upgrade your Linux kernel to the latest stable release that contains the patch for this nvmet recursive locking issue.
  • If upgrading immediately is not possible, monitor kernel logs closely for recursive locking warnings and avoid workloads that heavily use the nvmet subsystem to reduce the risk of triggering the issue.
Chat Assistant
Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-46304. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70
EPSS Chart