🇰🇷 한글 설명
Linux 커널의 iomap 메커니즘에서 iomap 콜백 실패 시 folio 배치를 적절히 해제하지 못하는 취약점이 발견되었습니다. iomap_begin() 또는 iomap_end() 호출이 실패할 경우 에러 경로에서 배치가 정리되지 않아 리소스 누수가 발생할 수 있습니다.
💡 쉬운 설명
컴퓨터의 메모리를 관리하는 과정에서 오류가 발생했을 때, 사용하던 메모리 묶음을 제대로 돌려주지 않고 놓쳐버리는 문제입니다. 이로 인해 시스템의 메모리 자원이 조금씩 낭비될 수 있습니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
iomap: release the folio batch on iomap callback failures
A sashiko review of an unrelated patch points out that the folio
batch mechanism used for iomap zero range fails to release the batch
in a couple error scenarios. If either calls to ->iomap_end() or
->iomap_begin() fail, the direct return paths bypass the batch
cleanup.
The ->iomap_end() case is not a practical issue at the moment
because there is no user of the mechanism that returns an error from
this path. The ->iomap_begin() case is theoretically possible
because XFS can invoke the fill helper and error out at various
points thereafter. This subtly complicates things because XFS does
not transfer iomap_flags to the iomap data structure in the error
path.
To deal with both of these issues, first make sure to invoke the
cleanup helper in the error path for either fs callback. Second,
update the helper to clear the flag unconditionally and release the
batch so long as it is populated. This more clearly delineates the
purpose of the flag to control the I/O path and not necessarily the
status of the fbatch, so add a comment around this as well.
📍 영향받는 시스템
Linux Kernel (iomap 관련 모듈을 사용하는 시스템, 특히 XFS 파일 시스템 사용 환경)
⚔️ 공격 벡터
특정 파일 시스템 작업 중 의도적인 에러를 유발하여 메모리 누수를 일으키는 방식
🛡️ 대응 방법
Linux 커널을 최신 보안 패치가 적용된 버전으로 업데이트하십시오.
🔧 검증 코드
출력된 커널 버전을 확인하여 해당 취약점이 해결된 패치 버전인지 확인하십시오.