CVE-2022-49901 in Linux
Сводка
по VulDB • 28.06.2026
В ядре Linux устранена следующая уязвимость:
blk-mq: Исправление утечки памяти kmemleak в функции blk_mq_init_allocated_queue
Наблюдается утечка памяти (kmemleak), вызванная загрузкой модуля null_blk.ko через modprobe.
Неиспользуемый объект 0xffff8881acb1f000 (размер 1024): comm "modprobe", pid 836, jiffies 4294971190 (возраст 27.068s) шестнадцатеричный вывод (первые 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...... трассировка стека (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
Это происходит потому, что q->ma_ops устанавливается в NULL до вызова blk_release_queue.
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 завершилась ошибкой при i != 0.
[2]: hctx, выделенные в [1], перемещаются в q->unused_hctx_list и будут очищены в blk_mq_release.
[3]: Значение q->nr_hw_queues равно 0.
[4]: Устанавливается значение NULL для q->mq_ops.
[5]: Функция queue_is_mq возвращает false из-за [4]. Следовательно, blk_mq_release не будет вызвана. Память под hctx в q->unused_hctx_list утекает (leaked).
Для исправления проблемы необходимо вызывать blk_release_queue в ветке обработки исключений (exception path).
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.