CVE-2022-49901 in Linux
Zusammenfassung
von VulDB • 28.06.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
blk-mq: Behebung eines kmemleak-Fehlers in blk_mq_init_allocated_queue
Es liegt ein durch das Laden von null_blk.ko mittels modprobe verursachter kmemleak vor.
unreferenziertes Objekt 0xffff8881acb1f000 (Größe 1024): comm "modprobe", pid 836, jiffies 4294971190 (Alter 27,068 s) Hex-Dump (erste 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
Dies liegt daran, dass q->ma_ops auf NULL gesetzt wird, bevor blk_release_queue aufgerufen wird.
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 ist bei i != 0 fehlgeschlagen.
[2]: Die von [1] zugewiesenen hctxs werden in q->unused_hctx_list verschoben und
in blk_mq_release bereinigt. [3]: q->nr_hw_queues ist 0.
[4]: Setzt q->mq_ops auf NULL.
[5]: queue_is_mq gibt aufgrund von [4] false zurück. Daher wird blk_mq_release
nicht aufgerufen. Die hctxs in q->unused_hctx_list werden nicht freigegeben (Leak).
Zur Behebung des Fehlers wird blk_release_queue im Ausnahmepfad aufgerufen.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.