Kernel v1·v2 연구 계보 · 공개 Linux Kernel CVE 2건 · Samsung Kernel audit 277 session
저는 대규모 Linux Kernel에서 AI가 조사할 타깃을 스스로 고르게 했을 때 발생한 낮은 분석 품질과 많은 오탐을 해결하기 위해, kernel domain knowledge와 syzbot을 External Signal로 점수화하는 Codex 연구 하네스를 설계했습니다. v1에서는 AI의 attention을 고위험 공격면에 배분했고, v2에서는 strong finding에 Git provenance를 결합해 재현 가능한 검토 큐로 발전시켰습니다.
왜 이 프로젝트를 시작했는가
Dreamhack: 시스템 해킹 성장 프로젝트에서 Kernel Exploit까지 학습한 뒤, AI를 실제 취약점 연구에 적극적으로 활용하고 싶었습니다. 먼저 최근 취약점이 반복해서 발견됐고, 문제가 발생했을 때 영향이 큰 대규모 저장소를 연구 대상으로 골랐습니다. 그러나 넓은 코드 범위를 AI에게 그대로 맡겨보니 분석이 눈에 띄는 API에 치우쳤고, 실제 reachability와 impact가 없는 오탐이 많이 나왔습니다.
저는 이 문제를 단순히 모델 성능의 한계로 보지 않았습니다. AI가 추론하기 전에 어디를 먼저 보게 할 것인가가 분석 품질을 좌우한다고 판단했습니다. 그래서 syzbot crash, kernel subsystem, userspace boundary와 위험 API를 External Signal로 정의하고, 파일별 점수로 변환해 제한된 조사 예산을 유망한 공격면에 집중시키는 하네스를 만들기 시작했습니다.
PROJECT OVERVIEW
항목 | 내용 |
기간 | 2026.04–2026.08 |
수행 형태 | 개인 Linux Kernel 취약점 연구 · Public research tooling |
문제 | 대규모 커널 소스에서 AI의 조사 범위가 분산되고, 위험한 API의 존재를 실제 취약점으로 오인해 false positive가 누적되는 문제 |
대상·환경 | Upstream Linux Kernel · Samsung Kernel source · Codex CLI · Git · syzbot |
분석·구현 범위 | 연구 대상 선정, kernel profile·lexical·userspace boundary·syzbot 기반 scoring, focused prompt와 session/autopilot, strict verdict ingest, Git provenance와 finding triage |
버전 발전 | Kernel v1 — Target Selection & Attention Allocation → Kernel v2 — Provenance-Aware Finding Triage |
결과 | CVE-2026-31720 · CVE-2026-53075 · Samsung Kernel initial·follow-up audit 277 session |
관련 연구 | Adaptive OSS Vulnerability Harness — 공통 철학에서 분기한 범용 OSS 후속 연구 |
linux-kernel-codex-harness
foxirain
linux-kernel-codex-harness-v2
foxirain
핵심 질문 — 대규모 Linux Kernel에서 External Signal로 AI의 조사 타깃을 먼저 선별하면 오탐을 줄이고 임펙트가 실제 취약 후보에 집중할 수 있는가? 그리고 AI가 낸 strong finding을 어떻게 재현 가능한 연구 결과로 관리할 것인가?
Project Flow
구분 | Kernel v1 | Kernel v2 |
핵심 질문 | AI가 어디를 먼저 볼 것인가 | AI가 낸 strong finding을 어떻게 믿고 관리할 것인가 |
Signal 시점 | 모델 실행 전 | 모델 응답 후 |
주요 입력 | Kernel profile · 위험 API · userspace boundary · syzbot | Git branch · HEAD · dirty state · CVE/fix reference |
주요 출력 | Ranked target와 focused investigation bundle | Provenance가 포함된 heuristic review queue |
명시적 비목표 | Score로 취약점을 자동 판정하지 않음 | Bucket으로 신규성을 자동 증명하지 않음 |
System Architecture
ROLE
Linux Kernel Vulnerability Researcher · AI Security Research Tooling Developer- 연구 설계 — 대규모 코드 탐색을 모델의 자율성 문제가 아니라 target selection과 attention allocation 문제로 정의했습니다.
- Kernel signal 설계 — subsystem, userspace boundary, 위험 API와 syzbot crash를 파일별 조사 우선순위로 변환했습니다.
- 하네스 구현 — ranked bundle, Codex session, strict verdict ingest, bounded follow-up와 시간 예산 기반 autopilot을 개발했습니다.
- 검증·공개 — 모델 결과에서 reachability, attacker control, kernel invariant와 impact를 직접 재검증하고 maintainer disclosure를 진행했습니다.
TECH STACK
Python · Codex CLI · Linux Kernel · Git · syzbot · BashSYSTEM DESIGN
1. 전체 아키텍처
이 구조에서 v1은 모델 실행 전에 분석 예산을 배분하고, v2는 모델 응답 뒤에 연구 결과의 기준점을 보존합니다. 두 단계 모두 취약점의 참·거짓을 직접 증명하지 않으며, 최종 증명은 Human Validation 경계 밖에 남겨뒀습니다.
MY WORK
1. 대규모 코드에서 AI 분석의 병목을 관찰
AI를 활용한 취약점 분석을 시작할 때, 첫 연구 대상은 이미 Linux Kernel로 정해두었습니다. 다만 커널 전체를 무작정 AI에게 맡기지는 않았습니다. 먼저 최근 취약점이 주로 발견된 subsystem과 userspace에서 도달 가능한 공격면을 직접 조사하고, 영향도와 분석 가치가 높다고 판단한 영역을 타깃으로 선별했습니다. 이후 선택한 타깃 범위의 코드를 AI에게 분석하도록 맡겼습니다.
하지만 직접 선별한 subsystem 전체를 AI에게 맡겨도 분석 범위는 여전히 넓었습니다. AI는 어느 파일과 경로부터 조사해야 하는지 일관되게 결정하지 못했고, 눈에 띄는 코드 주변에 탐색이 집중되거나 비슷한 영역을 반복하면서 제한된 실행 시간 안에 유의미한 coverage를 만들지 못하였고, cost만 소비할 뿐이었습니다.
관찰한 문제 | 원인에 대한 판단 | 설계 방향 |
선별한 subsystem도 AI가 한 번에 분석하기에는 범위가 넓음 | subsystem만 정했을 뿐 파일·함수 단위의 조사 우선순위가 없음 | 파일별 점수를 계산해 조사 순서를 결정 |
눈에 띄는 일부 파일과 코드 주변에 탐색이 집중됨 | 모델 내부 판단만으로 다음 조사 대상을 선택함 | 모델 외부의 재현 가능한 신호로 attention을 유도 |
비슷한 영역을 반복하며 제한된 시간 안에 유의미한 coverage를 만들지 못함 | 조사 단위와 탐색 범위의 종료 조건이 없음 | 한 번에 하나의 target을 분석하고 follow-up 범위를 제한 |
따라서 다음과 같은 가설이 생겼습니다.
핵심 가설 — 모델을 더 많이 호출하는 것보다, 모델이 보기 전에 조사 가치가 높은 작은 코드 단위를 골라주는 편이 coverage와 cost적으로 더 효과적일것이다.
이 가설에서 이 프로젝트가 시작되었습니다.
2. Kernel v1 — 커널 내부 신호로 기본 조사 후보를 점수화
1번에서 관찰한 문제를 해결하기 위해, Kernel v1에서는 사람이 고른 subsystem과 Codex 사이에 파일 선별 단계를 추가했습니다. 선택한 영역 전체를 바로 Codex에게 넘기는 대신, 하네스가 파일별 조사 우선순위를 먼저 계산하고 Codex는 점수가 높은 파일부터 분석하도록 했습니다.
제가 조사 대상으로 골랐던 영역은
net, fs, bpf, io_uring, drivers 등의 profile로 정리했습니다. Profile은 하네스가 어느 directory를 검사할지, 그리고 해당 영역에서 어떤 코드 pattern을 중요하게 볼지를 정의한 규칙입니다.파일 선별에도 AI의 판단을 사용하지 않았습니다. 1번에서 정한 설계 방향에 따라, 파일의 kernel path와 코드 안에서 발견되는 pattern처럼 모델 실행 전에 계산할 수 있는 신호를 사용했습니다. 저는 이렇게 모델의 추론 밖에서 계산되고 같은 입력에서 다시 확인할 수 있는 정보를 External Signal이라고 정의했습니다.
- Path score — 파일이
net/,io_uring/,kernel/bpf/처럼 중요하게 설정한 kernel path에 있는가
- Line score — 파일의 각 line에서
ioctl, usercopy, allocation, refcount처럼 조사 가치가 있는 pattern이 발견되는가
하네스는 profile 범위에서 읽을 수 있는
.c와 .h 파일을 순회했습니다. line-pattern match가 하나라도 있거나, pattern이 없더라도 path score가 8 이상인 파일만 초기 후보로 남겼습니다.는 Codex에게 보낼 가치가 있다고 판단한 초기 파일 목록입니다. 코드에서 조사 pattern이 하나라도 발견된 파일은 후보로 남기고, pattern이 없어도 중요한 kernel path에 있어 path score가 8 이상이면 후보에 포함했습니다.
각 후보의 기본 attention score는 path weight와 line-pattern match weight의 합으로 계산했습니다.
예를 들어 어떤
net/ 파일이 path weight 8을 받고, 서로 다른 두 line에서 copy_from_user가 발견되어 각각 9, 다른 line에서 refcount pattern이 발견되어 7을 받았다면 이 됩니다. 이 합계가 높은 파일부터 Codex의 조사 대상으로 배치했습니다.기호 | 코드에서의 의미 | 읽는 방법 |
선택한 profile의 include directory 아래에서 읽기에 성공한 .c·.h 파일 | 사람이 고른 subsystem 안의 실제 검색 범위 | |
내장 path rule 의 문자열이 파일 경로 에 포함되면 1 | 일치한 path rule의 weight를 한 번 더함 | |
: profile regex 가 파일 의 line 에서 한 번 이상 일치한 사건 | 동일 pattern이 여러 line에서 일치하면 line별로 합산하고, 한 line 안의 반복 출현은 한 번만 합산 | |
은 내장 PATH_RULES, 는 선택한 profile pattern에 정의된 weight | AI 응답과 독립적으로 정해진 조사 우선순위 값 |
targeting.py는 모든 path·line match를 score에 합산합니다. 이후 Candidate와 Signal에는 path signal과 profile의 max_signals_per_file만큼의 상위 line signal을 남겼습니다. 따라서 artifact에는 주요 선정 이유가 보존되고, 정확한 score는 같은 source tree·profile·harness version으로 다시 계산할 수 있습니다.Priority is not probability. 는 취약점 확률, severity 또는 exploitability의 추정치가 아닙니다. 제한된 Codex 실행 시간 동안 어떤 파일을 먼저 조사할지 정하는 기본 조사 순서입니다.
3. syzbot: 기본 점수를 실제 crash history까지 확장
경로와 lexical signal만으로 조사 공간을 줄일 수는 있었지만, 이 신호들은 코드 표면의 정적 특징에 가까웠습니다. 저는 실제 커널 실행에서 반복적으로 깨진 지점을 조사 순서에 반영하기 위해 syzbot을 두 번째 External Signal layer로 연결했습니다.
syzbot-fetch는 공개 bug page에서 title, subsystem, bug type, crash count와 file:line을 추출해 로컬 JSON cache로 고정했습니다. live dashboard는 계속 변하므로, 동일한 ranking을 다시 계산할 수 있도록 fetch 시점의 JSON을 재현 단위로 삼았습니다.기본 점수에 syzbot overlap을 결합한 최종 점수는 다음과 같이 표현할 수 있습니다.
여기서 는 syzbot bug별 exact-file·subsystem-only indicator를 실제 구현 weight로 합산한 값입니다. exact-file hit에는 기본
18, 지정된 UAF·OOB 계열이면 추가 4, subsystem-only hit에는 5를 적용합니다.기호 | 의미 | 해석 경계 |
소문자로 바꾼 candidate path와 bug 의 file-hit path 중 한쪽이 다른 쪽의 suffix이면 1 | 구현상 exact file overlap으로 부르지만 엄밀한 path equality는 아님 | |
bug type이 use-after-free, slab-use-after-free, slab-out-of-bounds, out-of-bounds 중 하나이면 1 | 이 네 종류의 exact-file hit에만 추가 weight 4 적용 | |
이고 candidate path의 첫 디렉터리가 bug 의 subsystem 목록과 일치하면 1 | exact-file과 상호 배타적인 subsystem-only weight 5 | |
syzbot JSON의 bugs 입력 순서에서 candidate와 처음 일치한 최대 6개 bug | weight 상위 6개를 다시 고르는 방식이 아니라 구현 순서에 따른 cap |
중요한 구현 경계는 syzbot hit만으로 새로운 후보를 생성하지 않는다는 점입니다. syzbot은 이미 kernel path·line signal로 만들어진 의 순서만 조정합니다. 따라서 공개 crash를 그대로 재발견한 결과와 새로운 variant를 구분하기 위한 최종 reachability·impact·novelty 판단은 계속 사람에게 남겼습니다.
4. 정적분석기를 다시 만드는 대신 Codex와 증명 책임을 나눴습니다
당시 제 질문은 “AST, call graph, interprocedural data flow를 다시 구축하는 것이 정말 필요한가?”였습니다. Linux Kernel에는 이미 여러 정적분석·퍼징 체계가 적용되고 있었고, 제 목표는 그 체계를 하나 더 만드는 것이 아니라 Codex가 semantic investigator로 동작하도록 조사 범위와 증거 계약을 설계하는 것이었습니다.
강한 finding이 되기 위한 최소 조건은 다음 논리식으로 표현할 수 있습니다.
조건 | Codex가 설명해야 하는 증거 |
— Reachability | userspace에서 시작되는 실제 syscall·ioctl·netlink·filesystem·driver entrypoint |
— Attacker control | 공격자가 통제하는 field, length 또는 lifetime transition |
— Invariant break | 깨지는 object size, refcount, ownership, locking 또는 namespace invariant |
— Concrete impact | crash, corruption, leak 또는 privilege boundary 위반 |
— Effective guard | 기존 check·권한·config·device 조건이 공격 경로를 실제로 차단하는지 |
하네스는 상위 후보를 한 파일과 가까운 caller·teardown·free path로 제한하고, 문맥이 부족하면 정확히 하나의
Single best next target만 반환하도록 했습니다. parser는 verdict와 next target을 정규화하지만 위 논리식의 참을 자동 증명하지 않습니다. reachability와 impact는 제가 소스와 실행 환경에서 다시 검증했습니다.5. Kernel v1에서 반복 가능한 조사 루프를 구현하고 실제 finding으로 검증했습니다
Kernel v1은 점수가 높은 후보를
targets.json에 순위와 이유와 함께 저장하고, target별 prompt와 local snippet을 생성했습니다. 수동 review와 autopilot은 동일한 review_state.json과 verdict parser를 사용했으며, manual follow-up은 최대 두 번으로 제한했습니다.이 구조의 목적은 Codex의 탐색 능력을 없애는 것이 아니라, 넓은 커널 트리에서 길을 잃지 않도록 시작점, 조사 단위, 종료 조건을 통제하는 것이었습니다. 이 v1-assisted 조사에서 USB gadget audio control request의 host-controlled length가 fixed-size stack object의 경계를 넘는 문제를 발견했고, 직접 검증과 disclosure를 거쳐 CVE-2026-31720으로 공개했습니다.
6. Kernel v2 — strong finding 뒤에 Git provenance 기반 triage를 추가했습니다
v1에서 “AI가 어디를 볼 것인가”는 개선됐지만, “AI가 낸 strong finding을 어떤 기준점에서 믿고 관리할 것인가”가 다음 문제로 남았습니다. 기존 CVE의 재발견, 이미 포함된 fix commit, 로컬 실험 patch와 불명확한 HEAD가 finding을 오염시킬 수 있었습니다.
v2에서는
repo_state.py로 branch, HEAD, Git status, dirty path와 commit ancestry를 수집하고, finding_triage.py가 strong verdict에만 다음 우선순위 함수를 적용하도록 만들었습니다.- — Git repository, status와 HEAD를 신뢰성 있게 확인했는가
- — repository 또는 target file이 dirty한가
- — non-negated CVE·known marker가 있거나, fix/upstream으로 지목된 commit이 현재 HEAD의 ancestor인가
구분 | Kernel v1 | Kernel v2 |
질문 | 어디를 먼저 조사할 것인가 | strong finding을 어떤 상태에서 검토할 것인가 |
Signal 시점 | 모델 실행 전 | 모델 응답 후 |
독립 관찰값 | path · lexical hit · cached syzbot overlap | branch · HEAD · status · dirty path · local ancestry |
결과 | ranked target | provenance-aware review bucket |
증명하지 않는 것 | 취약점의 존재·심각도 | finding의 신규성 |
특히
new_candidate는 새로운 취약점이라는 뜻이 아닙니다. 현재 checkout과 응답에서 known·dirty·provenance 차단 신호를 찾지 못했다는 의미뿐이며, 모든 bucket에 novelty_proven=false를 기록했습니다.7. 장시간 연구를 재현 가능한 artifact와 검토 큐로 운영했습니다
Samsung Kernel을 대상으로 277개의 initial·follow-up audit session을 운영하면서, 단일 실행 품질만큼 중단·재개, stale response 격리, parse failure 보존, repository 기준점 고정이 중요하다는 것을 확인했습니다.
Artifact | 보존한 정보 | 운영 목적 |
targets.json | candidate score · signal · selection reason | target selection 재구성 |
bundles/*.md · *.snippet.txt | target별 prompt와 local evidence | focused review 반복 실행 |
review_state.json | pending target · verdict · follow-up depth · history | 중단된 session 재개와 stale response 격리 |
AUTOPILOT_BASELINE.json | run 시작 시 branch · HEAD · dirty files | repository 기준점 고정 |
AUTOPILOT_FINDINGS.jsonl | verdict · bucket · reason · provenance · matched reference | 후처리 가능한 human review queue |
기본 sandbox는
read-only로 유지하고, clean tree가 중요한 실행에는 doctor와 --require-clean-tree를 사용했습니다. negative verdict가 strong finding으로 뒤집히지 않는지, follow-up 제한, stale response archive, provenance fail-closed와 bucket metadata 보존을 regression test로 고정했습니다.이 v2-assisted 후속 조사에서는 PPP administrative ioctl이 target network namespace의 user namespace에 대해
CAP_NET_ADMIN을 검증하지 않는 권한 경계 문제를 발견했고, 직접 검증과 disclosure를 거쳐 CVE-2026-53075로 공개했습니다.RESULTS
핵심 성과
- 대규모 코드의 AI 분석 문제를 Target Selection → Attention Allocation → Focused Investigation → Provenance-Aware Triage 흐름으로 재정의했습니다.
- Kernel v1과 v2를 사용한 조사에서 공개 Linux Kernel CVE 2건을 발견하고 책임 있게 공개했습니다.
- syzbot과 kernel domain knowledge를 취약점 판정이 아닌 Codex 조사 우선순위로 변환했습니다.
- Samsung Kernel initial·follow-up audit 277 session을 운영하며 중단·재개·후속 조사와 결과 provenance를 상태로 남겼습니다.
- parser, stale response, follow-up depth, package resource와 sandbox 기본값을 회귀 테스트로 보강했습니다.
공개 결과
연구 단계 | 공개 결과 | 검증한 보안 경계 |
Kernel v1 | USB gadget audio control length와 fixed-size stack object 사이의 memory boundary | |
Kernel v2 | PPP administrative ioctl과 target network namespace의 capability boundary |
한계
- 당시에는 External Signal 도입 전후의 false positive와 target quality를 같은 corpus에서 측정하지 않아 precision·recall 개선 수치를 주장하지 않습니다.
- Codex가 따라간 호출·데이터 경로를 독립적으로 증명하거나 전체 공격면 coverage를 계산하는 분석기는 아니므로, reachability와 impact는 사람이 다시 검증해야 합니다.
- syzbot 연동은 공개 HTML에서 bug와 file·subsystem overlap을 가져오는 adapter이며, reproducer·fix commit·stack semantics까지 자동 분석하지는 않습니다.
- 공개 저장소의 현재 main에는 이후 추가한 parser·provenance·안전성·회귀 테스트 보강이 포함돼 있으므로, 실제 조사 당시 구현과 현재 공개 구현을 구분합니다.
배운 점과 다음 단계
이 프로젝트를 통해 AI 분석의 품질은 모델 자체뿐 아니라 무엇을 먼저 보여주고, 어떤 증거를 요구하며, 결과를 어떤 repository state와 함께 남기는가에 크게 좌우된다는 것을 배웠습니다. External Signal은 AI가 어디를 볼지는 개선할 수 있지만, 무엇이 취약점이고 새로운 문제인지는 증명하지 못했습니다. 그래서 최종 검증과 공개 판단은 계속 사람의 책임으로 남겼습니다.
이후 Adaptive OSS Vulnerability Harness에서는 이 철학 일부를 재사용했지만, Kernel의 상위호환을 만들지는 않았습니다. 커널 전용 syzbot pipeline과 invariant 중심 설계 대신, 언어와 공격면이 다른 범용 OSS에서 External Signal을 통제하고 여러 탐색 가설에 예산을 배분하는 별도의 연구 방향으로 분기했습니다.
전체 기록과 원본
- Kernel v1 — Target Selection과 Attention Allocation · linux-kernel-codex-harness
- Kernel v2 — Provenance-Aware Finding Triage · linux-kernel-codex-harness-v2
- 공개 CVE 증거와 재현 자료 · CVE-public
- 비공개 연구 원본 · Codex JSONL session, Samsung campaign artifact와 disclosure 전 자료는 공개 경계를 지키며 별도 보관