🇰🇷 한글 설명
Linux 커널의 dax/fsdev에서 정적 장치 해제 시 pgmap의 ops와 owner가 초기화되지 않는 취약점이 발견되었습니다. 이로 인해 장치가 재연결되거나 모듈이 언로드될 때, 이미 해제된 이전 핸들러를 참조하여 메모리 오류 발생 시 시스템 불안정이나 예기치 않은 동작을 유발할 수 있습니다.
💡 쉬운 설명
장치를 컴퓨터에서 제거했다가 다시 연결할 때, 예전에 사용하던 잘못된 정보가 남아 있어 시스템이 혼란을 겪는 문제입니다. 이로 인해 메모리에 문제가 생겼을 때 컴퓨터가 비정상적으로 작동할 수 있습니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
dax/fsdev: clear pgmap ops and owner on unbind
fsdev_dax_probe() sets pgmap->ops = &fsdev_pagemap_ops and
pgmap->owner = dev_dax, but nothing ever clears them. For a dynamic
device the pgmap is devm-allocated and freed on unbind, so this is
harmless. For a static device the pgmap is the shared, long-lived one
owned by the dax bus (kill_dev_dax() only NULLs dev_dax->pgmap for the
non-static case), and device.c's probe sets only pgmap->type, never
clearing ops/owner.
So after fsdev unbinds a static device the stale fsdev_pagemap_ops
survives on the shared pgmap. If the device is then rebound to
device_dax (MEMORY_DEVICE_GENERIC, which installs no ->memory_failure),
or the fsdev_dax module is unloaded, a subsequent memory_failure on that
pgmap dispatches through the stale -- and possibly freed -- handler.
Register a devm action that clears pgmap->ops and pgmap->owner on unbind,
symmetric with setting them at probe, so the pgmap carries no fsdev state
once fsdev is detached.
📍 영향받는 시스템
Linux kernel (dax/fsdev 관련 정적 장치 사용 환경)
⚔️ 공격 벡터
정적 장치의 unbind 및 rebound 과정을 통한 잘못된 메모리 핸들러 호출 유도
🛡️ 대응 방법
Linux 커널 패치를 적용하여 장치 해제(unbind) 시 pgmap의 ops와 owner를 명시적으로 초기화해야 함
🔧 검증 코드
출력된 커널 버전이 해당 취약점이 수정된 최신 패치 버전인지 확인하십시오.