🇰🇷 한글 설명
리눅스 커널의 mm/shrinker 구성 요소에서 debugfs를 통해 NULL 포인터 역참조가 발생할 수 있는 취약점이 발견되었습니다. 특정 shrinker가 count_objects() 또는 scan_objects() 콜백을 구현하지 않은 상태에서 debugfs 파일에 접근할 경우 커널 패닉이 발생합니다.
💡 쉬운 설명
컴퓨터의 메모리를 관리하는 프로그램이 특정 기능을 수행할 준비가 안 되어 있는데, 강제로 그 기능을 실행하려고 시도하여 시스템이 멈추는 문제입니다. 이로 인해 시스템이 갑자기 재부팅되거나 중단될 수 있습니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
mm: shrinker: fix NULL pointer dereference in debugfs
shrinker_debugfs_add() creates both "count" and "scan" debugfs files
unconditionally.
That assumes every shrinker implements both count_objects() and
scan_objects(), which is not guaranteed. For example, the xen-backend
shrinker sets count_objects() but leaves scan_objects() NULL, so writing
to its scan file calls through a NULL function pointer and panics the
kernel:
BUG: kernel NULL pointer dereference, address: 0000000000000000
RIP: 0010:0x0
Code: Unable to access opcode bytes at 0xffffffffffffffd6.
Call Trace:
<TASK>
shrinker_debugfs_scan_write+0x12e/0x270
full_proxy_write+0x5f/0x90
vfs_write+0xde/0x420
? filp_flush+0x75/0x90
? filp_close+0x1d/0x30
? do_dup2+0xb8/0x120
ksys_write+0x68/0xf0
? filp_flush+0x75/0x90
do_syscall_64+0xb3/0x5b0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
The count path has the same issue in principle if a shrinker omits
count_objects().
To fix it, only create "count" and "scan" debugfs files when the
corresponding callbacks are present.
📍 영향받는 시스템
Linux Kernel (shrinker debugfs 관련 모듈을 사용하는 시스템)
⚔️ 공격 벡터
로컬 사용자가 debugfs의 scan 또는 count 파일을 통해 NULL 함수 포인터를 호출하여 커널 패닉 유도
🛡️ 대응 방법
해당 취약점이 수정된 최신 리눅스 커널 버전으로 업데이트
🔧 검증 코드
출력된 커널 버전이 해당 취약점이 패치된 배포판의 보안 업데이트 버전인지 확인