Look up another CVE · open CVE-2024-49569 in the interactive tracker
CVE-2024-49569
nvme-rdma: unquiesce admin_q before destroy it
Published 2025-01-11 (21 months ago) by the Linux kernel CNA. Subsystem drivers/nvme. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2024-49569 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | fixed | 6.12.5-1 | Update the kernel and reboot. Fixed in 6.12.5-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 6.12.5-1 | Update the kernel and reboot. Fixed in 6.12.5-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 6.12.5-1 | Update the kernel and reboot. Fixed in 6.12.5-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
Kernel will hang on destroy admin_q while we create ctrl failed, such as following calltrace: PID: 23644 TASK: ff2d52b40f439fc0 CPU: 2 COMMAND: "nvme" #0 [ff61d23de260fb78] __schedule at ffffffff8323bc15 #1 [ff61d23de260fc08] schedule at ffffffff8323c014 #2 [ff61d23de260fc28] blk_mq_freeze_queue_wait at ffffffff82a3dba1 #3 [ff61d23de260fc78] blk_freeze_queue at ffffffff82a4113a #4 [ff61d23de260fc90] blk_cleanup_queue at ffffffff82a33006 #5 [ff61d23de260fcb0] nvme_rdma_destroy_admin_queue at ffffffffc12686ce #6 [ff61d23de260fcc8] nvme_rdma_setup_ctrl at ffffffffc1268ced #7 [ff61d23de260fd28] nvme_rdma_create_ctrl at ffffffffc126919b #8 [ff61d23de260fd68] nvmf_dev_write at ffffffffc024f362 #9 [ff61d23de260fe38] vfs_write at ffffffff827d5f25 RIP: 00007fda7891d574 RSP: 00007ffe2ef06958 RFLAGS: 00000202 RAX: ffffffffffffffda RBX: 000055e8122a4d90 RCX: 00007fda7891d574 RDX: 000000000000012b RSI: 000055e8122a4d90 RDI: 0000000000000004 RBP: 00007ffe2ef079c0 R8: 000000000000012b R9: 000055e8122a4d90 R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000004 R13: 000055e8122923c0 R14: 000000000000012b R15: 00007fda78a54500 ORIG_RAX: 0000000000000001 CS: 0033 SS: 002b This due to we have quiesced admi_q before cancel requests, but forgot to unquiesce before destroy it, as a result we fail to drain the pending requests, and hang on blk_mq_freeze_queue_wait() forever. Here try to reuse nvme_rdma_teardown_admin_queue() to fix this issue and simplify the code.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/nvme/host/rdma.c
- What this is
- NVM EXPRESS DRIVERMAINTAINERS section matched on drivers/nvme/host/ · linux-nvme@lists.infradead.org · Supported
- Kernel module
- nvme_rdma
Check it on the machine
grep -w CONFIG_NVME_RDMA /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w nvme_rdmaPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.
- bookworm, trixie, forky, sidm
- m
- a loadable module on every flavour - check lsmod, can be blacklisted
- Build switch
- CONFIG_NVME_RDMA
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2025-01-11 (21 months ago)source
- CVSS
- 7.5 high
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.82%, higher than 56.6% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/nvme
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.12 | 6.6.88 | 427036030f4d |
| 5.12 | 6.12.5 | 05b436f3cf65 |
| 5.12 | 6.13 | 5858b6875598 |
| 5.4.103 | 0 | 0 |
| 5.10.21 | 0 | 0 |
| 5.11.4 | 0 | 0 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:NAttack vector, network
- The error path that hangs is selected entirely by data the remote NVMe-oF target supplies over the fabric (ICDOFF and the keyed-SGL bit in Identify Controller, or refusal of I/O-queue connect), and RoCEv2/iWARP are routable IP transports, so a malicious or compromised target reachable over the network drives the bug. NVMe-oF host/target sessions are ordinary network protocol exchanges, matching the treatment of other nvme fabrics host-side flaws.
- AC:LAttack complexity, low
- The target only has to advertise a non-zero icdoff or clear NVME_CTRL_SGLS_KSDBDS to deterministically force the host into the destroy_admin path, and any admin request left undispatched on the quiesced queue makes the freeze wait forever. The attacker can also re-drive controller creation repeatedly via discovery-log-change AENs, so no condition outside their control must happen to line up.
- PR:NPrivileges required, none
- The attacker is the remote peer and needs no credentials on the victim host — NVMe-oF requires no mandatory authentication, and there is no capable() check anywhere on the nvmf_dev_write → nvme_rdma_setup_ctrl path. The host-side privileged action is performed by the system's own autoconnect tooling, not by the attacker.
- UI:NUser interaction, none
- On hosts configured for NVMe-oF, systemd/udev autoconnect creates controllers (new=true) automatically in response to discovery-log-change AENs from the target, so no human action is needed at exploitation time.
- S:UScope, unchanged
- The hang is confined to the kernel's own block/NVMe layer and the calling process; no security authority or isolation boundary is crossed.
- C:NConfidentiality impact, none
- The defect is a missing unquiesce leading to an indefinite wait in blk_mq_freeze_queue_wait(); no freed or out-of-bounds memory is read and nothing is disclosed to the attacker.
- I:NIntegrity impact, none
- There is no memory corruption, no write primitive, and no unintended state modification — the queue simply never drains, so no data can be altered.
- A:HAvailability impact, high
- The calling task blocks forever in TASK_UNINTERRUPTIBLE and is unkillable, holding nvmf_dev_mutex so every later /dev/nvme-fabrics operation on the system wedges too, pinning the module and preventing clean shutdown; the hung-task watchdog fires and panics the box when hung_task_panic is set.