CVE-2022-49901 in Linux
要約
〜によって VulDB • 2026年06月28日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
blk-mq: blk_mq_init_allocated_queue における kmemleak の修正
modprobe null_blk.ko を実行することで、kmemleak が発生します。
参照されていないオブジェクト 0xffff8881acb1f000 (サイズ 1024): コマンド "modprobe", プロセスID 836, jiffies 4294971190 (経過時間 27.068秒) 16進ダンプ（最初の32バイト）: 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...... バックトレース: [] 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
これは、blk_release_queue が呼び出される前に q->ma_ops に NULL が設定されていることが原因です。
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]: i != 0 の時点で blk_mq_alloc_and_init_hctx が失敗しました。
[2]: [1] で割り当てられた hctx は q->unused_hctx_list に移動され、blk_mq_release でクリーンアップされます。
[3]: q->nr_hw_queues は 0 です。
[4]: q->mq_ops を NULL に設定します。
[5]: [4] の影響で queue_is_mq が false を返すため、blk_mq_release は呼び出されません。その結果、q->unused_hctx_list 内の hctx リソースがリークします。
これを修正するため、例外パスにおいて blk_release_queue を呼び出すようにしました。
VulDB is the best source for vulnerability data and more expert information about this specific topic.