🇰🇷 한글 설명
Linux 커널의 GCOV 인스트루멘테이션 과정에서 GCC 최적화로 인해 전역 분기 카운터가 루프 유도 변수와 병합되면서 발생하는 동시성 접근 취약점입니다. 여러 CPU에서 동시에 IPComp(IP 페이로드 압축) 처리가 수행될 때 카운터 값이 불일치하게 되어 메모리 경계를 벗어난 쓰기(Out-of-bounds write)가 발생하고 시스템 크래시를 유발할 수 있습니다.
💡 쉬운 설명
여러 개의 CPU가 동시에 데이터를 압축 해제할 때, 계산용 숫자가 중간에 갑자기 바뀌면서 메모리의 잘못된 위치에 데이터를 적는 오류입니다. 이로 인해 컴퓨터 시스템이 갑자기 멈추거나 오류가 발생할 수 있습니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
gcov: use atomic counter updates to fix concurrent access crashes
GCC's GCOV instrumentation can merge global branch counters with loop
induction variables as an optimization. In inflate_fast(), the inner copy
loops get transformed so that the GCOV counter value is loaded multiple
times to compute the loop base address, start index, and end bound. Since
GCOV counters are global (not per-CPU), concurrent execution on different
CPUs causes the counter to change between loads, producing inconsistent
values and out-of-bounds memory writes.
The crash manifests during IPComp (IP Payload Compression) processing when
inflate_fast() runs concurrently on multiple CPUs:
BUG: unable to handle page fault for address: ffffd0a3c0902ffa
RIP: inflate_fast+1431
Call Trace:
zlib_inflate
__deflate_decompress
crypto_comp_decompress
ipcomp_decompress [xfrm_ipcomp]
ipcomp_input [xfrm_ipcomp]
xfrm_input
At the crash point, the compiler generated three loads from the same
global GCOV counter (__gcov0.inflate_fast+216) to compute base, start, and
end for an indexed loop. Another CPU modified the counter between loads,
making the values inconsistent - the write went 3.4 MB past a 65 KB
buffer.
Add -fprofile-update=prefer-atomic to CFLAGS_GCOV at the global level in
the top-level Makefile, guarded by a try-run compile test. The test
compiles a minimal program with and without -fprofile-update=prefer-atomic
using the full KBUILD_CFLAGS, then compares undefined symbols in the
resulting object files. If prefer-atomic introduces new undefined
references (such as __atomic_fetch_add_8 on i386 or __aarch64_ldadd8_relax
on arm64 with outline-atomics), the flag is not added -- the kernel does
not link against libatomic.
On architectures where GCC inlines 64-bit atomic counter updates (x86_64,
s390, ...) the test passes and the flag is enabled, preventing the
compiler from merging counters with loop induction variables and fixing
the observed concurrent-access crash.
On architectures where the flag would introduce libatomic dependencies, it
is silently omitted and behaviour is no worse than before this patch.
Move the CFLAGS_GCOV block from its original position (before the arch
Makefile include) to after the core KBUILD_CFLAGS assignments but before
the scripts/Makefile.gcc-plugins include. This placement ensures the
try-run test sees arch-specific flags (-m32, -march=,
-mno-outline-atomics) while avoiding GCC plugin flags (-fplugin=) that
would break the test on clean builds when plugin shared objects do not yet
exist.
📍 영향받는 시스템
GCOV 프로파일링이 활성화된 상태로 컴파일된 Linux 커널 (특히 IPComp를 사용하는 시스템)
⚔️ 공격 벡터
멀티코어 환경에서 조작된 IPComp 패킷을 전송하여 동시성 충돌을 유도함으로써 메모리 손상 및 시스템 크래시 유발
🛡️ 대응 방법
커널 Makefile에 -fprofile-update=prefer-atomic 플래그를 적용하여 GCOV 카운터 업데이트를 원자적(Atomic) 방식으로 수정
🔧 검증 코드
출력된 커널 버전이 해당 취약점이 패치된 최신 보안 업데이트 버전인지 확인