🇰🇷 한글 설명
Linux 커널의 GFS2 파일 시스템에서 iomap 인라인 데이터 쓰기 경로 중 Use-After-Free 취약점이 발견되었습니다. gfs2_iomap_begin() 함수에서 데이터 버퍼가 실제 사용되기 전에 조기에 해제되어, 이후 iomap_write_end_inline()이 해당 메모리에 접근할 때 오류가 발생합니다.
💡 쉬운 설명
파일을 저장하는 과정에서 컴퓨터가 사용 중인 메모리 공간을 너무 빨리 비워버리는 버그입니다. 이로 인해 이미 사라진 메모리 공간에 데이터를 쓰려고 시도하다가 시스템이 충돌하거나 오류가 발생할 수 있습니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
gfs2: Fix use-after-free in iomap inline data write path
The inline data buffer head (dibh) is being released prematurely in
gfs2_iomap_begin() via release_metapath() while iomap->inline_data
still points to dibh->b_data. This causes a use-after-free when
iomap_write_end_inline() later attempts to write to the inline data
area.
The bug sequence:
1. gfs2_iomap_begin() calls gfs2_meta_inode_buffer() to read inode
metadata into dibh
2. Sets iomap->inline_data = dibh->b_data + sizeof(struct gfs2_dinode)
3. Calls release_metapath() which calls brelse(dibh), dropping refcount
to 0
4. kswapd reclaims the page (~39ms later in the syzbot report)
5. iomap_write_end_inline() tries to memcpy() to iomap->inline_data
6. KASAN detects use-after-free write to freed memory
Fix by storing dibh in iomap->private and incrementing its refcount
with get_bh() in gfs2_iomap_begin(). The buffer is then properly
released in gfs2_iomap_end() after the inline write completes,
ensuring the page stays alive for the entire iomap operation.
Note: A C reproducer is not available for this issue. The fix is based
on analysis of the KASAN report and code review showing the buffer head
is freed before use.
[agruenba: Take buffer head reference in gfs2_iomap_begin() to avoid
leaks in gfs2_iomap_get() and gfs2_iomap_alloc().]
📍 영향받는 시스템
Linux kernel (GFS2 파일 시스템을 사용하는 시스템)
⚔️ 공격 벡터
로컬 공격자가 GFS2 파일 시스템을 사용하는 환경에서 특수한 파일 쓰기 작업을 수행하여 메모리 오류 유도
🛡️ 대응 방법
Linux 커널을 최신 보안 패치가 적용된 버전으로 업데이트하여 버퍼 참조 관리 로직을 수정해야 함
🔧 검증 코드
현재 실행 중인 커널 버전을 확인하여 해당 취약점이 해결된 패치 버전인지 확인합니다.