CVE-2023-52707 in Linux
요약
\~에 의해 VulDB • 2026. 05. 24.
리눅스 커널에서 다음 취약점이 해결되었습니다:
sched/psi: ep_remove_wait_queue()에서의 use-after-free 수정
트리거를 등록하고 cgroup 내의 압력(pressure) 파일에서 폴링 중인 스레드가 있는 상태에서 루트가 아닌 cgroup이 제거되면, 폴링 대기열(waitqueue)이 다음 경로에서 해제됩니다:
do_rmdir cgroup_rmdir kernfs_drain_open_files cgroup_file_release cgroup_pressure_release psi_trigger_destroy
그러나 폴링 스레드는 여전히 압력 파일에 대한 참조를 보유하고 있으며, 파일이 닫히거나 종료될 때 해제된 대기열에 접근합니다:
fput ep_eventpoll_release ep_free ep_remove_wait_queue remove_wait_queue
이로 인해 아래에 표시된 대로 use-after-free가 발생합니다.
여기서의 근본적인 문제는 cgroup_file_release() (및 결과적으로 대기열의 수명)가 파일의 실제 수명과 연결되어 있지 않다는 것입니다. 여기서 wake_up_pollfree()를 사용하는 것이 이상적이지는 않을 수 있지만, 대기열의 수명이 파일의 수명과 연결되어 있지 않으며 다른 특수한 경우로 간주될 수 있으므로 커밋 42288cb44c4b("wait: add wake_up_pollfree()")의 주석과 일치합니다. cgroup_file_release()를 fput()에 연결함으로써 이를 수정할 수는 있지만, cgroups 또는 상위 레이어에서 상당한 리팩토링이 필요하며, 이와 유사한 사례를 더 많이 식별한다면 더 정당화될 수 있습니다.
BUG: KASAN: use-after-free in _raw_spin_lock_irqsave+0x60/0xc0 Write of size 4 at addr ffff88810e625328 by task a.out/4404
CPU: 19 PID: 4404 Comm: a.out Not tainted 6.2.0-rc6 #38 Hardware name: Amazon EC2 c5a.8xlarge/, BIOS 1.0 01/01/2011 Call Trace: <TASK> dump_stack_lvl+0x49/0x70 print_report+0xc4/0x319 kasan_report+0xb1/0x130 _raw_spin_lock_irqsave+0x60/0xc0 remove_wait_queue+0x27/0x110 ep_remove_wait_queue+0x23/0x110 ep_free+0x103/0x140 ep_eventpoll_release+0x1c/0x30 __fput+0x101/0x2a0 ____fput+0x9/0x10 task_work_run+0x98/0xc0 exit_to_user_mode_prepare+0x111/0x120 syscall_exit_to_user_mode+0x17/0x30 do_syscall_64+0x44/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd
Allocated by task 4404:
kasan_set_track+0x3d/0x60 __kasan_kmalloc+0x85/0x90 psi_trigger_create+0x113/0x3e0 pressure_write+0x146/0x2e0 cgroup_file_write+0x11c/0x250 kernfs_fop_write_iter+0x186/0x220 vfs_write+0x3d8/0x5c0 ksys_write+0x90/0x110 do_syscall_64+0x43/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd
Freed by task 4407:
kasan_set_track+0x3d/0x60 kasan_save_free_info+0x27/0x40 ____kasan_slab_free+0x11d/0x170 slab_free_freelist_hook+0x87/0x150 __kmem_cache_free+0xcb/0x170 psi_trigger_destroy+0x2e8/0x310 cgroup_file_release+0x4f/0xb0 kernfs_drain_open_files+0x165/0x1f0 kernfs_drain+0x162/0x1a0 __kernfs_remove+0x1fb/0x310 kernfs_remove_by_name_ns+0x95/0xe0 cgroup_addrm_files+0x67f/0x700 cgroup_destroy_locked+0x283/0x3c0 cgroup_rmdir+0x29/0x100 kernfs_iop_rmdir+0xd1/0x140 vfs_rmdir+0xfe/0x240 do_rmdir+0x13d/0x280 __x64_sys_rmdir+0x2c/0x30 do_syscall_64+0x43/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.