🇰🇷 한글 설명
리눅스 커널의 memcg에서 folio가 노드 간 이동 시 기존의 objcg를 그대로 유지하여 발생하는 취약점입니다. 이로 인해 objcg의 재부모화와 LRU 리스트의 재부모화가 원자적으로 이루어지지 않아, 잘못된 memcg의 lru_lock을 획득하게 됩니다.
💡 쉬운 설명
데이터가 저장되는 메모리 위치가 바뀔 때, 관리 정보가 제때 업데이트되지 않아 시스템이 혼란을 겪는 문제입니다. 이로 인해 메모리 관리 과정에서 충돌이 발생하거나 시스템 안정성이 떨어질 수 있습니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
memcg: keep folio's objcg same as its node
memcg_reparent_objcgs() has an inherent assumption that a folio's objcg is
the objcg of the folio's node. Folio migration across nodes breaks that
assumption: the new folio simply inherits the old folio's objcg while
living on a different node.
Once the assumption is broken, the reparenting of the folio's objcg and
the reparenting of the folio's LRU list are no longer atomic.
memcg_reparent_objcgs() handles one node per iteration and drops all the
locks in between, so the objcg gets reparented in the iteration for the
objcg's node while the LRU list gets spliced in the iteration for the
folio's node. Any LRU operation on that folio in between resolves its
lruvec through the objcg, and thus takes the lru_lock of the wrong memcg,
not the lru_lock of the list the folio is actually on.
Fix this by selecting the objcg by folio_nid() at charge time, and by
re-deriving it for the destination node in mem_cgroup_migrate() and
mem_cgroup_replace_folio().
📍 영향받는 시스템
Linux Kernel (folio migration 관련 memcg 기능 사용 시)
⚔️ 공격 벡터
메모리 노드 간 이동(migration)을 유도하여 메모리 관리 로직의 동기화 오류를 유발
🛡️ 대응 방법
커널 패치를 통해 charge 시점에 folio_nid()를 사용하여 objcg를 선택하고, 이동 시 목적지 노드에 맞게 재도출하도록 업데이트
🔧 검증 코드
현재 실행 중인 커널 버전을 확인하여 해당 취약점이 해결된 패치 버전인지 확인