🇰🇷 한글 설명
Linux 커널의 xenbus 구성 요소에서 요청(request) 객체의 수명 주기를 적절히 관리하지 못해 발생하는 NULL 포인터 역참조 취약점입니다. 특정 상황에서 요청 객체가 이미 해제된 후 다시 접근하려고 시도할 때 커널 패닉이나 시스템 오류가 발생할 수 있습니다.
💡 쉬운 설명
컴퓨터가 이미 삭제된 데이터를 다시 사용하려고 시도하다가 오류가 발생하는 문제입니다. 이로 인해 시스템이 갑자기 멈추거나 비정상적으로 종료될 수 있습니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
xenbus: Use kref to track req lifetime
Marek reported seeing a NULL pointer fault in the xenbus_thread
callstack:
BUG: kernel NULL pointer dereference, address: 0000000000000000
RIP: e030:__wake_up_common+0x4c/0x180
Call Trace:
<TASK>
__wake_up_common_lock+0x82/0xd0
process_msg+0x18e/0x2f0
xenbus_thread+0x165/0x1c0
process_msg+0x18e is req->cb(req). req->cb is set to xs_wake_up(), a
thin wrapper around wake_up(), or xenbus_dev_queue_reply(). It seems
like it was xs_wake_up() in this case.
It seems like req may have woken up the xs_wait_for_reply(), which
kfree()ed the req. When xenbus_thread resumes, it faults on the zero-ed
data.
Linux Device Drivers 2nd edition states:
"Normally, a wake_up call can cause an immediate reschedule to happen,
meaning that other processes might run before wake_up returns."
... which would match the behaviour observed.
Change to keeping two krefs on each request. One for the caller, and
one for xenbus_thread. Each will kref_put() when finished, and the last
will free it.
This use of kref matches the description in
Documentation/core-api/kref.rst
📍 영향받는 시스템
Xenbus를 사용하는 Linux 커널 버전
⚔️ 공격 벡터
로컬 공격자가 특정 Xenbus 요청 시퀀스를 유도하여 커널의 NULL 포인터 역참조를 유발
🛡️ 대응 방법
kref를 사용하여 요청 객체의 수명을 관리하도록 수정된 최신 Linux 커널로 업데이트
🔧 검증 코드
현재 실행 중인 커널 버전을 확인하여 취약점이 해결된 패치 버전인지 확인합니다.