🔍 CVE-2026-98939

0.0
CVSS Score
UNKNOWN
2026-10-23
2026-10-23 13:17
✅ 완료

🇰🇷 한글 설명

Linux 커널 x86 메모리 관리 코드에서 PMD 페이지를 해제할 때 불필요한 PMD 페이지 복사를 제거한 수정입니다. 기존 코드는 mmap 잠금을 보유한 상태에서 GFP_KERNEL 할당을 수행하여 메모리 회수 경로와 교착 상태(deadlock)가 발생할 수 있었습니다. 복사 없이 분리된 PMD 페이지에서 직접 PTE 테이블을 해제하도록 변경되었습니다.

💡 쉬운 설명

리눅스 커널이 메모리를 정리하는 과정에서 두 작업이 서로를 기다리며 멈출 수 있는 문제가 있었습니다. 불필요한 메모리 할당을 없애서 이 멈춤 가능성을 제거했습니다.

🇺🇸 원문 (English)

In the Linux kernel, the following vulnerability has been resolved: x86/mm: Drop unnecessary PMD page copy when freeing On a box with a discrete GPU, lockdep reports a possible deadlock as soon as kswapd shrinks the TTM page pool. The immediate cause is an x86 commit that added an mmap_read_lock() to kernel page protection munging code. The huge vmap code holds the same lock over a GFP_KERNEL allocation, which is a no-no now that reclaim can take it. That allocation is in a page table *free* path and ends up being for dubious purposes[1]. Basically, it tries to avoid hardware setting Accessed=1 in page table entries that are unreachable by the hardware, a non-issue. Remove the PMD copy. Detach the original PMD page at the PUD, flush the mid-level caches, and free the PTE tables straight from the detached PMD page. With no allocation left, the locking issue is gone. Lockdep splat/analysis: WARNING: possible circular locking dependency detected 7.3.0-rc3-f6e7b42bf05b+ #183 Tainted: G U ------------------------------------------------------ kswapd0/269 is trying to acquire lock: ((init_mm).mmap_lock){++++}-{4:4}, at: change_page_attr_set_clr+0x29a/0x4a0 but task is already holding lock: (pool_shrink_rwsem){.+.+}-{4:4}, at: ttm_pool_shrink+0xb2/0x330 [ttm] Chain exists of: (init_mm).mmap_lock --> fs_reclaim --> pool_shrink_rwsem The cycle is built from three edges: 1) pool_shrink_rwsem -> (init_mm).mmap_lock The TTM shrinker restores the caching attribute of every page it frees, while holding pool_shrink_rwsem: ttm_pool_shrink() -> ttm_pool_dispose_list() -> ttm_pool_free_page() -> set_pages_wb() -> change_page_attr_set_clr() [ init_mm mmap read lock ] 2) fs_reclaim -> pool_shrink_rwsem The same shrinker, called from reclaim. 3) (init_mm).mmap_lock -> fs_reclaim ioremap() installing a huge PUD mapping over an existing PMD table: ioremap_page_range() -> vmap_range_noflush() -> vmap_try_huge_pud() [ init_mm mmap read lock ] -> pud_free_pmd_page() -> __get_free_page(GFP_KERNEL) [ enters reclaim ] [ dhansen: Lots of changelog munging/trimming and merged comments from my version of the fix. ]

📍 영향받는 시스템

패치 이전의 x86 아키텍처 기반 Linux 커널 (별도 GPU 등 메모리 회수가 빈번한 환경에서 lockdep 경고 확인됨)

⚔️ 공격 벡터

직접적인 원격 공격 경로는 명시되지 않았으며, 메모리 압박 상황에서 발생하는 커널 교착 상태(서비스 거부 가능성)로 보입니다.

🛡️ 대응 방법

패치가 적용된 최신 Linux 커널 버전으로 업데이트하거나 배포판 보안 업데이트를 설치하십시오.

🔧 검증 코드

출력된 커널 버전을 배포판의 보안 권고문과 대조하여 해당 수정이 포함된 빌드인지 확인하며, 최신 패치 버전이면 취약점이 해결된 것입니다.

Shell / Script
uname -r

💻 영향받는 소프트웨어

Linux Kernel