Skip to main content
cve.nowby Sazabi
← All vulnerabilities
CVE-2026-31557

nvmet: move async event work off nvmet-wq

Affects Linux kernel NVMe target (nvmet) code in several stable branches. The fix is in 6.6.160, 6.12.80, 6.18.21, and 6.19.11, with 5.16 and 5.18 for the older lines.

Published
Last modified
published
Not listed in CISA KEV
Unclear
Fix
Fixed in 5.16, 5.18, 6.6.160, 6.12.80, 6.18.21, and 1 more
None on Exploit-DB, Metasploit or GitHub
  • Exploitation: none
  • Automatable: yes
  • Technical impact: partial

Summary

In the Linux kernel, the following vulnerability has been resolved: nvmet: move async event work off nvmet-wq For target nvmet_ctrl_free() flushes ctrl->async_event_work. If nvmet_ctrl_free() runs on nvmet-wq, the flush re-enters workqueue completion for the same worker:- A. Async event work queued on nvmet-wq (prior to disconnect): nvmet_execute_async_event() queue_work(nvmet_wq, &ctrl->async_event_work) nvmet_add_async_event() queue_work(nvmet_wq, &ctrl->async_event_work) B. Full pre-work chain (RDMA CM path): nvmet_rdma_cm_handler() nvmet_rdma_queue_disconnect() __nvmet_rdma_queue_disconnect() queue_work(nvmet_wq, &queue->release_work) process_one_work() lock((wq_completion)nvmet-wq) <--------- 1st nvmet_rdma_release_queue_work() C. Recursive path (same worker): nvmet_rdma_release_queue_work() nvmet_rdma_free_queue() nvmet_sq_destroy() nvmet_ctrl_put() nvmet_ctrl_free() flush_work(&ctrl->async_event_work) __flush_work() touch_wq_lockdep_map() lock((wq_completion)nvmet-wq) <--------- 2nd Lockdep splat: ============================================ WARNING: possible recursive locking detected 6.19.0-rc3nvme+ #14 Tainted: G N -------------------------------------------- kworker/u192:42/44933 is trying to acquire lock: ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90 but task is already holding lock: ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x53e/0x660 3 locks held by kworker/u192:42/44933: #0: ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x53e/0x660 #1: ffffc9000e6cbe28 ((work_completion)(&queue->release_work)){+.+.}-{0:0}, at: process_one_work+0x1c5/0x660 #2: ffffffff82d4db60 (rcu_read_lock){....}-{1:3}, at: __flush_work+0x62/0x530 Workqueue: nvmet-wq nvmet_rdma_release_queue_work [nvmet_rdma] Call Trace: __flush_work+0x268/0x530 nvmet_ctrl_free+0x140/0x310 [nvmet] nvmet_cq_put+0x74/0x90 [nvmet] nvmet_rdma_free_queue+0x23/0xe0 [nvmet_rdma] nvmet_rdma_release_queue_work+0x19/0x50 [nvmet_rdma] process_one_work+0x206/0x660 worker_thread+0x184/0x320 kthread+0x10c/0x240 ret_from_fork+0x319/0x390 Move async event work to a dedicated nvmet-aen-wq to avoid reentrant flush on nvmet-wq.

Timeline

  1. CVE published
  2. CISA SSVC assessment

    Exploitation: none · Automatable: yes · Technical impact: partial

  3. Record last updated

Affected versions

  • Linux Linux

    From 5.15.42 · fixed in 5.16; From 5.17.10 · fixed in 5.18

  • Linux Linux

    5.18

  • KernelLinux

    From 5.18.0 · fixed in 6.6.160; From 6.7.0 · fixed in 6.12.80; From 6.13.0 · fixed in 6.18.21; From 6.19.0 · fixed in 6.19.11

References 6

git.kernel.org

FAQ

Questions about CVE-2026-31557

What does this mean?

The fix moves async event work off nvmet-wq, the workqueue the NVMe target uses. The advisory says that when nvmet_ctrl_free() runs on nvmet-wq, its flush of async_event_work re-enters the same workqueue.Source: git.kernel.org

Am I affected, and how do I check?

The listed ranges are Linux kernel 5.15.42 to before 5.16, 5.17.10 to before 5.18, 5.18.0 to before 6.6.160, 6.7.0 to before 6.12.80, 6.13.0 to before 6.18.21, and 6.19.0 to before 6.19.11. Compare the kernel version from uname -r against these ranges, and check whether the NVMe target (nvmet) module is in use.Source: git.kernel.org

What should I do about it?

Upgrade to a kernel release at or past the fixed version for your branch: 5.16 or later for the 5.15 line, 5.18 or later for the 5.17 line, 6.6.160, 6.12.80, 6.18.21, or 6.19.11.Source: git.kernel.org

Is it being exploited?

It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data