Microsoft security update for CVE-2024-49569
🔗 CVE IDs covered (1)
📋 Microsoft's advisory
EchelonGraph does not copy Microsoft's advisory page: its FAQ and remediation text are not shown here. Read the advisory on https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-49569. This page also shows what EchelonGraph holds for CVE-2024-49569, with the description from its CVE record, which the CVE Numbering Authority that assigned the CVE wrote: for a CVE Microsoft assigned, often in the words of Microsoft's own advisory.
🎯 Affected products7
- azl3 kernel 6.6.85.1-4 on Azure Linux 3.0
- azl3 kernel 6.6.92.2-1 on Azure Linux 3.0
- cbl2 kernel 5.15.186.1-1 on CBL Mariner 2.0
- cbl2 kernel 5.15.200.1-1 on CBL Mariner 2.0
- cbl2 kernel 5.15.202.1-1
- cbl2 kernel 5.15.202.1-1 on CBL Mariner 2.0
- cbl2 kernel 5.15.202.1-1 on CBL-Mariner 2.0
✅ Updates Microsoft lists: 2 updates
2 rows: one per KB article or update, update type and fixed build. Their details are on Microsoft's advisory.
| KB article | Update | Fixed build |
|---|---|---|
| — | Security Update | 6.6.92.2-1 |
| — | Security Update | — |
🧭 EchelonGraph on CVE-2024-49569
- EchelonGraph score
- 5.7 MEDIUM
- CISA KEV
- Not listed
- Fix status
- A fix is available — apply it.
Description from the CVE record (CVE.org), as published by its numbering authority
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.
Published by kernel.org, the CVE Numbering Authority that assigned CVE-2024-49569, in its CVE record at CVE.org; reused under the CVE Program's Terms of Use (its licence and MITRE's copyright notice are in our Terms of Service).