
CVE-2026-98432: 일반 IPv4 TCP 서버가 취약하며, MPTCP는 트리거가 아닙니다. 버그 트리거, 증거 및 분석.
DeepSeek이 작성했습니다.
일반 IPv4 TCP 서버가 취약합니다. MPTCP는 트리거가 아닙니다.
우리는 릴리스 tarball에서 Linux 6.18.55를 빌드하고, 일반 IPPROTO_TCP 리스너에서 커널이 해제된 메모리를 읽도록 만들었습니다. KASAN이 이를 두 번 보고했습니다. MPTCP 소켓은 한 번도 생성되지 않았고, 한 실행에서는 커널에서 MPTCP가 꺼져 있었습니다.
같은 버그로 인해 커널은 해제된 객체에서 바이트를 복사하여 다시 보내는 응답에 넣습니다. 이것이 KASLR 우회에 필요한 프리미티브이며, 우리는 미공개 작업에서 이것이 발생하는 것을 관찰했습니다. 우리는 커널 주소 누출을 구축하지 않았고, 쓰기를 증명하지도 않았습니다.
여기서 코드와 로그로 증명되는 것은 use-after-free가 실제이며, 기본 TCP가 여기에 도달하고, 업스트림 수정이 이를 막는다는 것입니다.
| 커널 | MPTCP | 시도 횟수 | 시간 | 결과 |
|---|---|---|---|---|
| 6.18.55, 수정 없음 | 사용 안 함 | 134,955 | 34 s | KASAN use-after-free |
| 6.18.55, 수정 없음 | 꺼짐 | 191,431 | 80 s | KASAN use-after-free |
| 6.18.55 + 수정 | 사용 안 함 | 439,316 | 411 s | 정상 |
매우 어렵습니다. KASAN에서는 리더가 느리기 때문에 버그가 수십만 번의 시도 내에 나타납니다. 일반 커널에서는 훨씬 더 드뭅니다. 약 4,800만 번의 시도에서 두 번의 이벤트를 보았고, 둘 다 같은 5초 이내에 발생했습니다.
이는 비율을 명시하기에는 너무 적습니다. 우리가 주장할 수 있는 최대치는 시도당 대략 1e-7의 상한이며, 이마저도 최선의 경우입니다. 왜냐하면 우리의 하네스는 두 패킷을 두 CPU에 강제로 배치하지만 실제 NIC는 보통 하나의 플로우를 하나의 CPU로 보내기 때문입니다.
따라서 정상 실행이 안전한 커널을 의미하지는 않습니다. 어떤 수치를 인용하기 전에 ANALYSIS.md의 5.2절과 6절을 읽으십시오.
TCP 서버가 SYN을 받습니다. SYN은 IPv4 옵션(Record Route 또는 Timestamp)을 포함합니다. 커널은 해당 옵션들을 request 소켓에 저장합니다.
같은 연결에 대한 두 번째 SYN이 도착합니다. 커널은 이에 대한 SYNACK을 만들고 저장된 옵션을 읽습니다.
동시에 핸드셰이크가 완료됩니다. 자식 소켓은 복사본이 아닌 같은 포인터를 받습니다. 서버가 자식을 닫고, 커널은 일반 kfree()로 옵션을 해제합니다.
SYNACK 코드는 여전히 그 메모리를 읽고 있습니다. 이것이 use-after-free입니다. 같은 읽기가 해제된 바이트를 패킷에 넣는 원인입니다.
이것은 익스플로잇이 아닌 버그 트리거입니다. 커널 주소를 누출하지 않고, 커널 메모리에 쓰지 않으며, root를 얻지도 않습니다. 커널이 해제된 메모리를 읽는 것을 보여주며, KASAN이 판정자입니다.
저장소는 의도적으로 거기서 멈춥니다. 이후 단계는 비공개로 작업되었으며 여기에 게시되지 않습니다.
scripts/get-kernel.sh # fetch 6.18.55, sha256 checked, into linux/
scripts/build-kernel.sh vuln # KASAN kernel, no fix
scripts/build-kernel.sh patched # KASAN kernel, with the fix
scripts/build-harness.sh # builds harness/init + initramfs
scripts/run.sh vuln 90 selftest # checks the wiring only
scripts/run.sh vuln 600 # expect a KASAN report
scripts/run.sh patched 600 # expect nothing
gcc, make, bison, flex, bc 그리고 qemu-system-x86_64가 필요합니다. KVM은 큰 도움이 됩니다.
VM은 2 GB RAM과 8개의 vCPU를 사용합니다.
한 번의 실행으로는 아무것도 나타나지 않을 수 있습니다. 그것은 안전한 커널의 증거가 아닙니다. 여러 번
실행하고, ANALYSIS.md의 주의 사항을 읽으십시오.
버전 문자열을 신뢰하지 마십시오. 바이너리 내부의 코드를 살펴보십시오.
scripts/check-free-sites.py
실행 중인 커널에서 두 개의 free 사이트를 찾아내고, 각 사이트가 어떤 함수를 호출하는지 보여줍니다: kfree(취약) 또는 kvfree_call_rcu(수정됨).
이 문서를 작성한 머신(6.18.59_1)에서는 두 사이트 모두 kvfree_call_rcu를 사용하므로 해당 커널은 수정된 상태입니다.
다음 세 가지가 모두 참이면 호스트가 노출됩니다:
공격자는 2번 항목을 제어합니다. 따라서 대부분의 인터넷 서버가 노출되며, "우리는 MPTCP를 사용하지 않는다"는 것은 도움이 되지 않습니다.
두 가지 참고 사항:
accept_source_route=0은 보호해 주지 않습니다. 이는 소스 라우팅만 차단할 뿐, Record Route나 Timestamp는 차단하지 않습니다.| 경로 | 설명 |
|---|---|
ANALYSIS.md | 전체 보고서: 소스 경로, 방법, 결과, 한계 |
harness/ | QEMU에서 /init으로 실행되는 버그 트리거 |
patches/ | 대조 빌드에 사용된 업스트림 수정 |
scripts/ | 가져오기, 빌드, 실행 및 확인 헬퍼 |
evidence/ | KASAN 보고서, 실행 로그, 빌드 비교 |
테스트 커널에만, 그리고 본인이 소유한 커널에만 사용하십시오. 여기의 어떤 것도 본인이 제어하지 않는 시스템을 향해서는 안 됩니다.
당사의 코드와 텍스트에는 MIT를 적용합니다. patches/에는 Linux 커널 커밋이 포함되어 있으며 GPL-2.0을 따릅니다. LICENSE를 참조하십시오.