Answer in brief
CVE-2024-49569 records a High severity (CVSS 7.5) vulnerability in nvme-rdma: unquiesce admin_q before destroy it. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.5. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Product | Affected versions | Fixed versions |
|---|---|---|
| cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | Not reported | Not reported |
| cpe:2.3:o:linux:linux_kernel:6.13:rc1:*:*:*:*:*:* | Not reported | Not reported |
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | 5.12 | Not reported |
| Linux/Linuxgeneric | >=958dc1d32c80566f58d18f05ef1f05bd32d172c1 <427036030f4d796533dcadba9b845896cb6c10a7 || >=958dc1d32c80566f58d18f05ef1f05bd32d172c1 <05b436f3cf65c957eff86c5ea5ddfa2604b32c63 || >=958dc1d32c80566f58d18f05ef1f05bd32d172c1 <5858b687559809f05393af745cbadf06dee61295 || a9ea34d2717a8c8892d3c5677329de9485e325ac || 7da81eaf8710130a9e63d7429627183be5a93787 || caed0b3851a4f52afd1ef77a27b30410fe7b68c7 || >=5.4.103 <5.5 || >=5.10.21 <5.11 || >=5.11.4 <5.12 | 427036030f4d796533dcadba9b845896cb6c10a7, 05b436f3cf65c957eff86c5ea5ddfa2604b32c63, 5858b687559809f05393af745cbadf06dee61295, 5.5, 5.11, 5.12 |
| Linux/Linuxgeneric | >=958dc1d32c80566f58d18f05ef1f05bd32d172c1 <53bdbe5dc80b5887af51d62bf44e50f56972db5f || >=958dc1d32c80566f58d18f05ef1f05bd32d172c1 <427036030f4d796533dcadba9b845896cb6c10a7 || >=958dc1d32c80566f58d18f05ef1f05bd32d172c1 <05b436f3cf65c957eff86c5ea5ddfa2604b32c63 || >=958dc1d32c80566f58d18f05ef1f05bd32d172c1 <5858b687559809f05393af745cbadf06dee61295 || a9ea34d2717a8c8892d3c5677329de9485e325ac || 7da81eaf8710130a9e63d7429627183be5a93787 || caed0b3851a4f52afd1ef77a27b30410fe7b68c7 || >=5.4.103 <5.5 || >=5.10.21 <5.11 || >=5.11.4 <5.12 | 53bdbe5dc80b5887af51d62bf44e50f56972db5f, 427036030f4d796533dcadba9b845896cb6c10a7, 05b436f3cf65c957eff86c5ea5ddfa2604b32c63, 5858b687559809f05393af745cbadf06dee61295, 5.5, 5.11, 5.12 |
Published upstream
Jan 11, 2025
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 30, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
In the Linux kernel, the following vulnerability has been resolved: nvme-rdma: unquiesce admin_q before destroy it 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.
Quoted source text, attributed separately from HOL analysis.