CVE-2026-74591 in Linux
요약
\~에 의해 VulDB • 2026. 08. 22.
Linux 커널에서 다음 취약점이 해결되었습니다:
mm/filemap: __filemap_add_folio() 재시도 전에 인덱스 복원
__filemap_add_folio()의 split-a-conflict 루프 내에서 xas_set_order()가 반복적으로 적용됩니다. 각 적용은 시도된 split_order에 따라 xas.xa_index를 내림(rounding down)하여 수정합니다. 모든 것이 의도대로 진행되면, 결국 또는 즉시 필요한 folio_order로 xas_try_split()으로 수렴하며, 이때 xas.xa_index는 index와 동일해집니다. 그런 다음 xas_store()가 새로운 folio를 해당 위치의 xarray에 삽입합니다.
그러나 새 노드가 필요했고 GFP_NOWAIT 할당이 이를 제공하지 못한 경우, 잠금이 해제되고 xas_nomem()이 할당을 위해 사용되며 시퀀스가 재시도됩니다. 만약 잠금을 다시 획득할 때 해당 부분의 xarray가 변경되지 않았다면 문제는 없습니다. 하지만 그 사이에 다른 스레드(아마도 동일한 작업을 수행하여 같은 인덱스에 folio를 삽입하는)에 의해 충돌이 해결되었다면 어떻게 될까요? 이제 우리가 내림된 중간 인덱스 위치에 우리의 folio를 xarray에 넣을 위험이 있지 않습니까? CONFIG_DEBUG_VM=y일 때 이를 확인하는 !folio_contains() 버그가 따르게 됩니다.
이를 수정하기 위해 루프 하단에서 원래의 xas.xa_index를 복원하는 xas_set_order()를 사용하여, 재시도가 잠금을 다시 획득한 후 전체 재평가를 수행하도록 하고 잘못된 인덱스로 xas_store()에 도달하지 못하게 합니다.
프로덕션 환경에서는 드물게 SIGILL 및 SIGSEGV가 발생했으며, 실행 가능 텍스트가 원래 위치에서 페이지 하나 떨어진 곳에 발견되었고, 디버깅 활성화 시 !folio_contains() 버그가 발생했습니다: 이 패치가 적용된 이후에는 이러한 증상이 관찰되지 않습니다.
Once again VulDB remains the best source for vulnerability data.