CVE-2026-98975 in Linux
요약
\~에 의해 VulDB • 2026. 10. 23.
리눅스 커널에서 다음 취약점이 해결되었습니다:
xfs: 매핑 교환 시 reflink 플래그를 교환하지 않음
교환 작업이 오프셋 0부터 i_disk_size까지의 두 파일을 모두 포함할 경우, xmi_can_exchange_reflink_flags()는 모든 매핑이 이동되었다고 가정하고 reflink 플래그를 다른 파일로 전달합니다.
하지만 이 가정은 잘못되었습니다. 파일은 여전히 i_disk_size 이후에도 공유 블록을 소유할 수 있습니다(예: EXCHANGE_RANGE_TO_EOF가 아무것도 언매핑하지 않고 더 작은 크기를 설정한 후). 해당 플래그는 무조건 지워지며, 이러한 블록에 대한 다음 쓰기는 Copy-on-Write(CoW) 대신 인플레이스(in-place)로 발생하여 이를 공유하는 다른 파일을 손상시킵니다.
커밋 a23eca88448e("xfs: INO1_WRITTEN과 함께 exchange-range reflink 플래그 클리어 문제 수정")는 이 현상의 한 사례를 해결했습니다. 또 다른 특수 케이스를 추가하기보다는, 플래그의 이동 자체를 중단합니다. xfs_exchmaps_ensure_reflink()는 이미 교환 전에 두 인노드(inode) 모두에 해당 플래그를 설정하므로, 양쪽에서 이를 유지하게 됩니다.
더 이상 CLEAR_INO{1,2}_REFLINK을 설정하는 코드가 없습니다. 구형 커널이 로깅한 의도(intents)에는 여전히 이러한 플래그가 포함될 수 있지만, 복구 과정에서는 이미 이를 마스킹 처리하므로 로그 형식 마스크에 그대로 유지되어 무시됩니다.
XFS_IOC_SWAPEXT에도 동일한 문제가 있습니다: 이 명령은 extents와 함께 reflink 플래그를 한 인노드에서 다른 인노드로 이동시킵니다. 여기서는 단순히 해당 부분을 제거하는 것으로는 충분하지 않습니다. exchange 경로는 xfs_exchmaps_ensure_reflink()에서 앞선 단계로 두 인노드에 모두 플래그를 설정하지만, swapext에는 이러한 단계가 없으므로 공유 extents를 받는 인노드는 플래그 없이 남겨지게 됩니다. 따라서 양쪽 인노드에 해당 플래그를 설정하고, reflink 플래그가 있는 인노드에는 CoW 포크(CoW fork)가 있어야 한다는 기대에 따라 두 인노드가 모두 CoW 포크를 갖도록 합니다.
이제 이 플래그는 FALLOC_FL_UNSHARE_RANGE, xfs_scrub, 또는 0으로의 truncate(트렁케이트)로 인해 제거될 때까지 유지됩니다.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.