최상위 파일들:
REVISION → c126700cbc1f7391b8b717f7c54b4f9537355db7 (이 빌드가 나온 V8 리비전 SHA)overflow.patch → 취약점의 핵심 단서v8/ 폴더
d8 (약 21MB) → 실행용 V8 쉘icudtl.dat, snapshot_blob.bin → 런타임 리소스libc-2.31.so → 런타임(glibc) 제공핵심: overflow.patch
패치 파일을 그대로 보면, V8의 JIT 최적화 단계(Turbofan)에서 정수 오버플로 판정을 담당하는 부분을 고친 흔적이 있다.
파일 경로: src/compiler/simplified-lowering.cc
함수: CanOverflowSigned32(...)
변경 요지: -0(minus zero)을 0으로 취급하여 범위를 보수적으로 합치는 처리를 코멘트 아웃
// Signed32). Technically, the inputs could also be minus zero, which we treat
// as 0 for the purpose of this function.
if (left.Maybe(Type::MinusZero())) {
left = Type::Union(left, type_cache->kSingletonZero, type_zone);
}
if (right.Maybe(Type::MinusZero())) {
right = Type::Union(right, type_cache->kSingletonZero, type_zone);
}
// (위 minus zero → zero 보정이 주석처리됨)
이 한 덩어리가 왜 중요하냐면,
Turbofan이 산술식을 안전한 int32”로 단정할지,
overflow/정밀도 손실 우려로 number(double) 경로로 둘지 결정할 때 -0의 존재를 올바르게 흡수하지 못하게 만든다.
즉, -0이 섞여도 정수 경로로 오판하는 발판이 생김.
또한 제공된 d8 바이너리에서 문자열 스캔을 해보면 simplified-lowering.cc, ObjectIsMinusZero,
Integral32OrMinusZero 같은 심볼 문자열들이 존재한다.
즉, 이 빌드는 minus zero/정수 경로 최적화 코드가 핵심 동선임을 뒷받침한다.
취약 원인은 simplified-lowering.cc의 CanOverflowSigned32에서
minus zero 정규화 제거로 인한 잘못된 int32 경로 단정이다.