CVE-2026-98357 in Linux
요약
\~에 의해 VulDB • 2026. 10. 06.
리눅스 커널에서 다음 취약점이 해결되었습니다:
IB/isert: 연결 해제 전에 지연된 제어 PDU 완료 작업을 기다림
isert_send_done()은 ISTATE_SEND_TASKMGTRSP, ISTATE_SEND_REJECT 및 ISTATE_SEND_TEXTRSP 완료 작업을 isert_comp_wq로 전달하고 반환합니다. 그 후 작업 항목이 실행되어 isert_completion_put() -> isert_put_cmd()를 호출하며, 이는 isert_conn->conn을 읽고 conn->cmd_lock을 획득합니다.
해당 작업 항목과 연결 해제(teardown) 간의 순서(ordering)가 보장되지 않습니다. isert_wait_conn()은 isert_release_work를 큐에 추가하여 isert_conn을 해제(free)하고, iscsit_close_connection()은 반환 직후 iscsit_conn을 해제하므로, 큐에 대기 중인 작업이 이미 해제된 메모리에서 실행될 수 있습니다.
연결당 지연된 제어 PDU 완료 작업을 카운트하고, 연결 해제 작업이 큐에 추가되기 전에 isert_wait_conn()이 이를 기다리게 합니다.
ISTATE_SEND_LOGOUTRSP는 의도적으로 카운트에 포함되지 않습니다: 해당 분기는 iscsit_logout_post_handler()를 실행하며, 이는 결국 conn->conn_wait_comp를 대기하게 됩니다. 이 완료 작업은 iscsit_close_connection()에서 iscsit_wait_conn()을 호출한 후에만 전송되므로, 여기서 기다리면 데드락(deadlock)이 발생합니다. 해당 대기는 기존 isert_wait4logout()에 그대로 유지됩니다.
다음 스플래트(splat)는 tracing printk()와 isert_do_control_comp()에 주입된 msleep(200)를 통해 윈도우(window)를 넓힌 커널에서 발생했습니다:
BUG: KASAN: slab-use-after-free in isert_put_cmd+0x53d/0x620 Read of size 8 at addr ffff8881054f1038 by task kworker/u17:1/182
CPU: 0 UID: 0 PID: 182 Comm: kworker/u17:1 Tainted: G B 7.2.0-rc5-TWIDE-gb8babf08acc7 #1 PREEMPT(lazy) Tainted: [B]=BAD_PAGE
Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: isert_comp_wq isert_do_control_comp Call Trace: <TASK> dump_stack_lvl+0x53/0x70 print_report+0xd0/0x630 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? _raw_spin_unlock_irqrestore+0x3e/0x70 ? isert_put_cmd+0x53d/0x620 kasan_report+0xce/0x100 ? isert_put_cmd+0x53d/0x620 isert_put_cmd+0x53d/0x620 ? isert_completion_put+0x305/0x330 ? isert_do_control_comp+0x2ef/0x310 process_one_work+0x633/0x1030 ? assign_work+0x11d/0x370 worker_thread+0x45b/0xd10 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x2c6/0x3b0 ? recalc_sigpending+0x15c/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x36e/0x5a0 ? __pfx_ret_from_fork+0x10/0x10 ? __switch_to+0x572/0xdd0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK>
Allocated by task 48: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __kmalloc_cache_noprof+0x158/0x370 isert_cma_handler+0x1e3/0x2ae0 cma_cm_event_handler+0x3e/0x240 cma_ib_req_handler+0x17d9/0x4490 cm_process_work+0x41/0x330 cm_work_handler+0x5727/0xc160 process_one_work+0x633/0x1030 worker_thread+0x45b/0xd10 kthread+0x2c6/0x3b0 ret_from_fork+0x36e/0x5a0 ret_from_fork_asm+0x1a/0x30
Freed by task 184: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kfree+0x121/0x380 iscsit_close_connection+0x7cf/0x1e60 iscsit_take_action_for_connection_exit+0x1b6/0x360 iscsi_target_tx_thread+0x472/0x690 kthread+0x2c6/0x3b0 ret_from_fork+0x36e/0x5a0 ret_from_fork_asm+0x1a/0x30
If you want to get best quality of vulnerability data, you may have to visit VulDB.