CVE-2022-49901 in Linux
Summary
by MITRE • 05/01/2025
In the Linux kernel, the following vulnerability has been resolved:
blk-mq: Fix kmemleak in blk_mq_init_allocated_queue
There is a kmemleak caused by modprobe null_blk.ko
unreferenced object 0xffff8881acb1f000 (size 1024): comm "modprobe", pid 836, jiffies 4294971190 (age 27.068s) hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff 00 53 99 9e ff ff ff ff .........S...... backtrace: [] kmalloc_node_trace+0x22/0x60
[] blk_mq_alloc_and_init_hctx+0x289/0x350
[] blk_mq_realloc_hw_ctxs+0x2fe/0x3d0
[] blk_mq_init_allocated_queue+0x48c/0x1440
[] __blk_mq_alloc_disk+0xc8/0x1c0
[] 0xffffffffc450d69d
[] 0xffffffffc4538392
[] do_one_initcall+0xd0/0x4f0
[] do_init_module+0x1a4/0x680
[] load_module+0x6249/0x7110
[] __do_sys_finit_module+0x140/0x200
[] do_syscall_64+0x35/0x80
[] entry_SYSCALL_64_after_hwframe+0x46/0xb0
That is because q->ma_ops is set to NULL before blk_release_queue is called.
blk_mq_init_queue_data blk_mq_init_allocated_queue blk_mq_realloc_hw_ctxs for (i = 0; i nr_hw_queues; i++) {
old_hctx = xa_load(&q->hctx_table, i); if (!blk_mq_alloc_and_init_hctx(.., i, ..)) [1]
if (!old_hctx) break;
xa_for_each_start(&q->hctx_table, j, hctx, j) blk_mq_exit_hctx(q, set, hctx, j); [2]
if (!q->nr_hw_queues) [3]
goto err_hctxs;
err_exit: q->mq_ops = NULL; [4]
blk_put_queue blk_release_queue if (queue_is_mq(q)) [5]
blk_mq_release(q);
[1]: blk_mq_alloc_and_init_hctx failed at i != 0.
[2]: The hctxs allocated by [1] are moved to q->unused_hctx_list and
will be cleaned up in blk_mq_release. [3]: q->nr_hw_queues is 0.
[4]: Set q->mq_ops to NULL.
[5]: queue_is_mq returns false due to [4]. And blk_mq_release
will not be called. The hctxs in q->unused_hctx_list are leaked.
To fix it, call blk_release_queue in exception path.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 03/15/2026
The vulnerability described in CVE-2022-49901 resides within the Linux kernel's block multi-queue subsystem, specifically in the blk-mq implementation responsible for managing hardware queue contexts. This issue manifests as a memory leak occurring during the initialization of block queue structures when the null_blk kernel module is loaded via modprobe. The flaw demonstrates a classic kmemleak pattern where allocated kernel memory becomes unreferenced and cannot be reclaimed by the kernel's memory management system.
The technical root cause stems from improper error handling within the blk_mq_init_allocated_queue function where the queue's mq_ops structure is set to NULL before the blk_release_queue function is invoked. This sequence creates a scenario where hardware context structures (hctx) allocated during the initialization process are moved to the unused_hctx_list but never properly cleaned up. The conditional logic in the error path fails to call blk_release_queue when q->nr_hw_queues equals zero, which prevents the cleanup routine blk_mq_release from executing and consequently leads to memory leakage.
The operational impact of this vulnerability extends beyond simple memory consumption issues as it represents a potential denial of service vector that could gradually exhaust kernel memory resources over time. When the null_blk module is repeatedly loaded and unloaded, each instance contributes to accumulating unreferenced memory objects that persist in the kernel's memory space. This behavior violates the principle of proper resource management and can degrade system performance or stability under sustained load conditions.
The vulnerability aligns with CWE-401: "Improper Release of Memory Before Removing Last Reference" and demonstrates patterns consistent with ATT&CK technique T1490: "Inhibit System Recovery" through memory exhaustion. The fix implemented addresses this by ensuring that blk_release_queue is called in all error paths, specifically modifying the exception handling to guarantee cleanup of hardware contexts even when initialization fails partway through the process. This remediation ensures that all allocated memory structures are properly returned to the kernel's memory pool regardless of the initialization outcome, thereby preventing the accumulation of unreferenced objects that characterize kmemleaks.
The backtrace analysis reveals a clear execution path where kmalloc_node_trace allocates memory that becomes unreachable due to the premature NULL assignment of q->ma_ops. The function chain shows how blk_mq_alloc_and_init_hctx fails at a specific iteration, causing the error handling path to skip the proper cleanup mechanism that would normally occur in blk_mq_release. This represents a classic case of resource management failure where the error handling logic does not account for all possible code paths that could lead to allocated resources remaining unreferenced. The solution requires explicit cleanup calls in error conditions to maintain kernel memory integrity and prevent gradual resource exhaustion that could compromise system availability.