CVE-2026-53075 · foxirain

/dev/ppp open 권한은 file credential의 user namespace를 기준으로 검사했지만, unattached administrative ioctl은 현재 task가 속한 network namespace를 대상으로 삼았습니다. 새 user namespace의 CAP_NET_ADMIN만 가진 비특권 process가 상속한 기존 netns에서 PPPIOCNEWUNIT을 실행할 수 있는지 추적했습니다.

Upstream fix author: Taegu Ha · Linux kernel · authorization bypass · Linux CNA CVSS 8.8

2026년 6월 24일 공개 · mainline 및 stable tree에 수정 반영 · CVEProject 공식 레코드 · mainline fix 2bb6379416fd

한눈에 보기 공격 흐름 취약점 개요 조사 대상 원인 분석 재현 및 검증 판단 변화 — 자동 후보에서 CVE까지 대화를 바꾼 사용자 질문 1. 자동 후보 — 강한 가설이지만 아직 증명은 아님 2. 후보 비교와 권한 모델 재정의 3. “현재 환경에서 재현 불가”에서 커스텀 QEMU로 4. 첫 성공을 폐기하고 비특권 증명으로 다시 설계 5. userns harness 실패와 유효한 취약 baseline 확립 6. 작동하는 PoC에서 감사 가능한 제출 증거로 7. 보안 보고에서 fix engineering으로 전환 8. v1 → v2 → v3: 리뷰를 통한 최소 공통 gate 9. 호환성 주장과 증거 범위를 낮춰 쓰기 10. 제출 revision과 증거를 다시 동기화 11. upstream 수용과 CVE 배정을 분리 최종적으로 남은 판단 원칙 영향과 수정 재현 및 실제 도달 전제 동적으로 확인한 범위 정적으로 확인한 범위 실행하지 않았거나 증명하지 않은 범위 수정 영향 및 최초 수정 버전 분석 기준과 증거 보존 발견 및 검증 계보 관련 파일 2026-08-23 최종 감사 느낀 점 문서 수정 이력 2026-09-02 · 판단 변화 타임라인 보강 2026-08-31 · 원본 증거 정합성 교정 출처

한눈에 보기

🔎

Linux PPP ioctl이 file credential의 user namespace와 실제 target network namespace 사이의 권한 경계를 다시 확인하지 않았습니다. 동적 QEMU 검증은 PPPIOCNEWUNIT의 취약 성공과 패치 후 EPERM까지 수행했습니다. PPPIOCATTACH와 PPPIOCATTCHAN은 동일한 unattached dispatch와 공통 수정 gate에 의해 정적으로 영향 범위에 포함되지만 별도 runtime fixture로 실행하지 않았습니다.

구분	확인 내용
프로젝트·컴포넌트	Linux kernel PPP generic ioctl
공격 입력	동적 검증: `PPPIOCNEWUNIT` · 정적 영향 범위: `PPPIOCNEWUNIT`·`PPPIOCATTACH`·`PPPIOCATTCHAN`
필요 조건	local code execution, unprivileged userns 허용, PPP 활성화, `/dev/ppp` 및 device-cgroup 접근, 기존 netns 상속
취약 지점	unattached ioctl이 current task에서 선택한 target netns의 `user_ns`에 대한 capability check 누락
검증 결과	취약 baseline에서 상속 netns의 PPP unit 생성 성공, v3 patch에서 동일 `PPPIOCNEWUNIT`이 `EPERM`
영향	network namespace 경계의 authorization bypass
수정 원칙	`ns_capable(target_net->user_ns, CAP_NET_ADMIN)`로 실제 대상 netns 기준 검사

공격 흐름

✅

검증 결론: 현재 user namespace의 권한과 실제 PPP target namespace의 소유권이 분리될 때 authorization이 잘못 판단되는 namespace-boundary bypass를 확인했습니다.

취약점 개요

Linux capability는 process가 어떤 user namespace에서 권한을 갖는지에 따라 의미가 달라집니다. /dev/ppp를 연 file descriptor는 open 시점 credential과 연결되지만, unattached PPPIOCNEWUNIT, PPPIOCATTACH, PPPIOCATTCHAN은 현재 task의 target network namespace에 객체를 만들거나 연결합니다.

조사 당시 open authorization은 file->f_cred->user_ns를 기준으로 하고 administrative ioctl은 current->nsproxy->net_ns에서 동작했습니다. 로컬 비특권 사용자가 새 user namespace에서만 CAP_NET_ADMIN을 얻고 기존 network namespace를 상속하면 두 기준이 어긋날 수 있었습니다.

공격자 상태	새 user namespace 안에서만 `CAP_NET_ADMIN` 보유
대상	상속된 기존 network namespace
정적 영향 ioctl	`PPPIOCNEWUNIT`, `PPPIOCATTACH`, `PPPIOCATTCHAN`
핵심 누락	target netns owner user namespace에 대한 capability 검사

조사 대상

kernel namespace bug는 capability bit 하나만 확인해서는 설명할 수 없습니다. 권한을 가진 user namespace, 작업 대상 network namespace, file descriptor를 연 시점의 credential을 표로 나눴습니다.

ppp_unattached_ioctl()에 들어가는 세 administrative command가 어느 netns의 PPP state를 변경하는지 추적하고, 해당 netns를 소유한 user namespace에 ns_capable(..., CAP_NET_ADMIN) 검사가 있는지 확인했습니다.

새 user namespace에서 얻은 CAP_NET_ADMIN이 상속된 target netns의 PPP 관리 작업에도 잘못 인정되는가?

원인 분석

공격 process는 CLONE_NEWUSER로 새 user namespace를 만들면 그 안에서는 CAP_NET_ADMIN을 가질 수 있습니다. network namespace를 새로 만들지 않으면 current->nsproxy->net_ns는 기존 netns를 가리킵니다. 즉 capability의 소유 범위와 ioctl 대상이 서로 달라집니다.

기존 open check가 file credential 쪽 user namespace에서 통과해도 target netns를 관리할 권한을 보증하지 못했습니다. administrative ioctl 직전에 net->user_ns를 기준으로 검사해야 두 namespace가 일치합니다.

ppp_generic.c · 권한과 대상이 갈라진 지점


open('/dev/ppp')
  authorization -> file->f_cred->user_ns

ppp_unattached_ioctl(file, cmd, arg)
  target -> current->nsproxy->net_ns
  PPPIOCNEWUNIT / ATTACH / ATTCHAN

missing:
  ns_capable(target_net->user_ns, CAP_NET_ADMIN)

보존된 PoC의 실제 입력에서 영향까지의 경로

privileged QEMU init harness가 proc/sysfs/devtmpfs를 mount하고 /dev/ppp를 준비해 mode 0666으로 설정합니다. 이후 uid/gid 65534로 내려가며, 이 지점부터가 비특권 attack phase입니다.

network namespace는 유지한 채 unshare(CLONE_NEWUSER)만 실행합니다.

uid_map을 설정하고 새 userns 안에서 uid 0이 됩니다. 보존 PoC는 gid_map을 설정하지 않습니다.

같은 process가 userns 진입 후 /dev/ppp를 새로 open합니다. parent/child fd 전달은 사용하지 않습니다.

PPPIOCNEWUNIT을 호출해 취약 baseline에서는 unit 생성 성공, v3 patch에서는 EPERM을 관찰합니다.

재현 및 검증

보존된 최종 PoC는 privileged QEMU init harness에서 시작하는 fork 없는 단일 process입니다. harness setup이 proc/sysfs/devtmpfs를 mount하고 /dev/ppp를 생성·mode 0666으로 준비한 뒤 uid/gid 65534로 내립니다. 비특권 attack phase는 그 이후의 pre-userns open 실패 확인, CLONE_NEWUSER, uid_map, post-userns open, PPPIOCNEWUNIT 순서입니다. parent가 fd를 열어 child에 전달하는 흐름이나 gid_map, CLONE_NEWNET은 보존 PoC에 없습니다.

🧪

동적 검증 경계: 취약 kernel의 PPPIOCNEWUNIT succeeded와 v3 patched kernel의 Operation not permitted를 QEMU serial로 대조했습니다. PPPIOCATTACH·PPPIOCATTCHAN과 new userns+new netns 정상 대조군은 보존 로그에서 실행하지 않았습니다.


single process: uid=65534, gid=65534
pre-userns open('/dev/ppp') -> EPERM
unshare(CLONE_NEWUSER)       -> network namespace unchanged
write uid_map; setuid(0)     -> gid remains 65534
post-userns open('/dev/ppp') -> success
PPPIOCNEWUNIT               -> vulnerable: success / patched: EPERM

증거 유형	입력·조건	결과	판정
동적 · 취약 baseline	new userns + inherited netns + `PPPIOCNEWUNIT`	unit 0 생성 성공	권한 우회 실증
동적 · v3 patch	동일 namespace 조합과 ioctl	`EPERM`	수정 효과 실증
정적 분석	`PPPIOCNEWUNIT`·`PPPIOCATTACH`·`PPPIOCATTCHAN`	동일 unattached dispatch와 공통 pre-switch gate	세 ioctl 영향·수정 범위
미실행 대조군	new userns + new owned netns	보존 runtime 결과 없음	정상 허용은 정적 기대값

namespace 조합별 증거 상태


CASE A — dynamically validated
userns: new (CAP_NET_ADMIN here)
netns: inherited (not owned here)
vulnerable: PPPIOCNEWUNIT succeeds
patched:    PPPIOCNEWUNIT returns EPERM

CASE B — expected, not dynamically preserved
userns: new
netns: new and owned by that userns
expected: PPP admin ioctl allowed by ns_capable semantics

보존 PoC · 취약 QEMU log · 패치 QEMU log · upstream QEMU 검증 메일

판단 변화 — 자동 후보에서 CVE까지

🧭

이 섹션은 완성된 결론만 역순으로 설명하지 않습니다. 당시 판단, 사용자의 반론, 실패 로그, 추가 실험과 upstream review가 확신의 강도와 주장 범위를 어떻게 바꿨는지 순서대로 기록합니다. 원본 조사 session 자체는 공개하지 않고, 공개 증거로 확인 가능한 결과와 판단 전환만 요약합니다.

대화를 바꾼 사용자 질문

💬

“이미 CAP_NET_ADMIN이 필요한데도 취약점인가?” → capability bit가 아니라 어느 user namespace에서 유효한 권한인지 다시 보게 됐습니다.

“현재 서버에서 안 되면 QEMU로 직접 재현하면 되지 않나?” → 정적 후보를 커스텀 kernel의 동적 검증으로 전환했습니다.

“이 로그만으로 정말 증명된 것인가?” → 실행 성공과 제출 가능한 증거를 구분하고 깨진 harness 결과를 폐기했습니다.

“기존 결과 말고 실제 v3 상태를 다시 검증해야 하지 않나?” → 제출 patch revision과 PoC·QEMU 증거를 동기화했습니다.

1. 자동 후보 — 강한 가설이지만 아직 증명은 아님

당시 판단: 자동 분석은 ppp_open()의 file credential userns 검사와 unattached ioctl의 current netns 선택이 어긋날 수 있다고 보아 plausible_security_bug, confidence 8/10으로 분류했습니다.

남은 의문: 초기 자동 단계는 제한된 source 열람에 의존했고 runtime 증거가 없었습니다. /dev/ppp가 실제로 노출되는 배포 조건도 별도 전제였습니다.

추가 확인: 후속 대화에서 local baseline source의 open, ioctl dispatch, ppp_unattached_ioctl()과 생성 경로를 다시 추적했습니다.

수정된 판단: 자동 결과는 발견 후보로만 취급하고, 독립 local 분석과 동적 검증 전에는 확정 취약점이라고 부르지 않기로 했습니다.

2. 후보 비교와 권한 모델 재정의

당시 판단: 여러 후보 중 처음에는 하드웨어 관련 ENETC도 강하게 보였고, PPP는 CAP_NET_ADMIN이 필요하다는 점 때문에 보안 경계 침해인지 추가 설명이 필요했습니다.

전환 계기: 사용자가 “이미 capability가 필요한데 취약점이 맞는가”, “다른 stack에서 막히거나 의도된 설계는 아닌가”를 반복해서 물었습니다.

추가 증거: VFS open, PPP ioctl dispatcher, ppp_create_interface()까지 다시 확인했지만 target netns의 owner user namespace를 검사하는 하위 guard를 찾지 못했습니다. PPP는 물리 장비 없이도 QEMU에서 검증 가능한 명확한 namespace authorization 문제였습니다.

수정된 판단: 판단 기준을 “capability가 보이는가”에서 “그 capability가 변경 대상 netns를 소유한 userns에서 유효한가”로 바꿨고, PPP를 우선 실증 대상으로 올렸습니다.

3. “현재 환경에서 재현 불가”에서 커스텀 QEMU로

당시 판단: 조사 서버에는 /dev/ppp, 활성 PPP module과 필요한 guest 설정이 없어 처음에는 동적 재현이 어렵고 정적 보고만 가능하다고 봤습니다.

전환 계기: 사용자가 QEMU에서 필요한 kernel 기능을 직접 켜서 검증하자고 요구했습니다.

추가 증거: 기존 guest kernel에서 PPP와 USER_NS 설정이 빠진 것을 확인하고, CONFIG_PPP와 CONFIG_USER_NS를 활성화한 kernel과 최소 initramfs를 새로 구성했습니다.

수정된 판단: “재현 불가”는 취약점의 한계가 아니라 현재 host 환경의 한계였습니다. 이후부터는 정적 가능성보다 공격자 전제를 실제 guest에서 만족시키는 것을 증명 기준으로 삼았습니다.

4. 첫 성공을 폐기하고 비특권 증명으로 다시 설계

당시 결과: 첫 QEMU에서는 PPPIOCNEWUNIT이 성공했지만 테스트 process가 PID 1/root였습니다.

판정 철회: root가 같은 netns에서 관리 ioctl을 성공시킨 것은 정상 동작일 수 있으므로, 권한 우회 증거로 인정하지 않았습니다.

실험 수정: attack phase를 uid/gid 65534에서 시작하고, userns 진입 전 실패와 진입 후 성공을 같은 process에서 비교하도록 PoC 조건을 강화했습니다.

수정된 판단: 기대한 출력이 나왔다는 사실보다 공격자 전제와 대조 조건이 맞는지가 우선이며, 전제가 틀린 성공 결과는 폐기해야 한다는 기준이 확립됐습니다.

5. userns harness 실패와 유효한 취약 baseline 확립

실패: 비특권 실험 중 setgroups·gid_map, 이어서 uid_map 설정이 실패했습니다.

구분: 이 각 오류가 PPP authorization에서 나온 것이 아니라 user namespace mapping 절차에서 발생했으므로 취약점 반증으로 해석하지 않았습니다.

교정: 불필요한 gid_map을 제거하고 uid-only mapping, PR_SET_DUMPABLE과 guest userns 조건을 정리했습니다.

유효한 증명 조건: uid/gid 65534에서 pre-userns /dev/ppp open이 EPERM, CLONE_NEWUSER만 수행해 network namespace inode가 동일, uid mapping 뒤 post-userns open 성공, 이어서 PPPIOCNEWUNIT 성공을 모두 관찰했습니다.

수정된 판단: 이 시점에 정적 후보는 동적으로 재현된 namespace authorization bypass로 상승했습니다. 동적 확정 범위는 PPPIOCNEWUNIT 하나입니다.

6. 작동하는 PoC에서 감사 가능한 제출 증거로

당시 상태: 내부 QEMU 실행은 성공했지만, 사용자가 직접 반복하고 maintainer가 검토할 수 있는 형태는 아니었습니다.

사용자 피드백: run.sh, 실제 build·QEMU 명령, 깨끗한 guest serial log가 필요하다는 요구에 따라 화면 제어문자가 섞인 driver 출력과 serial 출력을 분리하고 명령을 기록했습니다.

두 번째 판정 철회: 첫 제출용 run은 guest가 proc/sysfs/devtmpfs용 디렉터리를 만들기 전에 mount하다 종료됐습니다. 성공 안내 문자열과 부팅 흔적이 있어도 PPP 코드까지 도달하지 않았으므로 “아직 증명되지 않았다”고 판정을 되돌렸습니다.

교정과 결과: mount 순서를 고친 뒤 다시 실행하고 실제 guest의 PPPIOCNEWUNIT succeeded 행만을 취약 증거로 채택했습니다. 마지막 kernel panic은 PID 1 테스트 init 종료 artifact로 분리했습니다.

교훈: “한 번 실행됐다”와 “명령·조건·결과가 보존되어 독립 검토 가능한 증거다”는 서로 다른 수준입니다.

7. 보안 보고에서 fix engineering으로 전환

전환 계기: security report 검토 뒤 Greg KH가 적용 가능한 patch를 요청하면서 발견·설명 단계에서 직접 수정안을 설계하는 단계로 넘어갔습니다.

초기 수정: v1은 영향받는 세 ioctl case 각각에 target-netns capability check를 반복했습니다. 같은 QEMU 공격에서 open은 유지되고 PPPIOCNEWUNIT만 EPERM으로 바뀌는 것을 확인했습니다.

새 판단 축: maintainer가 현재 PPP tools와 정상 container 사용을 깨뜨리지 않는지 질문하면서 “공격 차단”뿐 아니라 “정상 사용의 비회귀”가 patch acceptance의 핵심 조건으로 추가됐습니다.

수정 원칙: /dev/ppp open 자체를 광범위하게 막기보다, 실제 target netns를 변경하는 object operation 직전에 그 netns의 owner user namespace 기준 권한을 검사해야 했습니다.

8. v1 → v2 → v3: 리뷰를 통한 최소 공통 gate

v1: 세 command case마다 같은 검사가 반복되는 작동 가능한 prototype이었습니다.

v2: 리뷰를 반영해 switch 앞의 공통 조건부 검사로 합쳤습니다. 준비 중 working tree 수정이 실제 commit과 생성된 patch에 포함되지 않은 문제를 diff 검토로 발견해 stage·amend했습니다.

v3: command filtering 자체가 불필요하다는 리뷰를 받아 ppp_unattached_ioctl() 진입부에서 ns_capable(net->user_ns, CAP_NET_ADMIN)을 한 번 검사하는 최종 3-line gate로 단순화했습니다.

프로세스 학습: [PATCH net], Fixes: tag, self Reported-by 제거, DCO, get_maintainer.pl 기반 CC, revision 사이 24시간 규칙과 실제 전송 patch 확인까지 upstream 제출 품질의 일부로 다뤘습니다.

수정된 판단: 좋은 security patch는 취약 호출만 막는 데서 끝나지 않고, 권한 모델이 드러나는 가장 좁고 공통된 위치에 들어가며 제출 artifact도 검증되어야 합니다. netdev v3 patch

9. 호환성 주장과 증거 범위를 낮춰 쓰기

초기 기대: 새 userns가 소유한 새 netns에서는 ns_capable(net->user_ns, CAP_NET_ADMIN)이 통과하므로 정상 pppd가 유지될 것으로 판단했습니다.

전환 계기: reviewer의 조건부 LGTM과 사용자의 “그 정상 케이스를 실제로 실행한 근거가 있는가”라는 질문이 있었습니다.

확인 결과: 보존 QEMU archive에는 new userns+new owned netns CASE B 실행 로그가 없었습니다. PPPIOCATTACH와 PPPIOCATTCHAN도 별도 runtime fixture로 실행하지 않았습니다.

수정된 판단: CASE B는 정적 비회귀 기대값, 두 추가 ioctl은 공통 dispatch와 fix gate에 근거한 source-level 영향 범위로만 기록하고, 동적 관찰값처럼 표현하지 않기로 했습니다.

10. 제출 revision과 증거를 다시 동기화

전환 계기: PoC 설명을 보내기 직전 사용자가 과거 결과를 재사용하지 말고 실제 v3 상태에서 다시 테스트해야 한다고 제동을 걸었습니다.

추가 검증: 최종 v3가 적용된 guest를 다시 build·실행해 동일 attack path의 post-userns open은 성공하지만 PPPIOCNEWUNIT은 EPERM이 되는 것을 확인했습니다.

증거 판독: driver log에 남은 취약 버전용 success 안내가 아니라 실제 guest serial의 결과를 진실의 기준으로 삼았습니다.

수정된 판단: patch, PoC, 설명과 runtime log는 같은 code revision을 가리켜야 하며, 오래된 안내문보다 실제 실행 출력과 diff가 우선합니다. 취약 QEMU log · v3 patched QEMU log

11. upstream 수용과 CVE 배정을 분리

upstream 판단: reviewer LGTM과 netdev/net.git 적용은 수정할 실제 bug와 patch가 networking tree에서 기술적으로 수용됐다는 의미였습니다.

경계: patch merge가 곧 CVE 번호 배정이나 공식 severity 확정을 뜻하지는 않았습니다. 원본 조사 session 종료 시점에는 CVE ID가 없었고 stable·released tree 반영과 Linux CNA 절차는 별도 단계였습니다.

사후 변화: 세션 중 severity는 잠정적으로 Medium 수준을 예상했지만, 이후 Linux CNA가 CVE-2026-53075와 CVSS 8.8 High를 공식 공개했습니다. 현재 문서는 잠정 추정이 아니라 공식 레코드를 기준으로 합니다.

최종 판단: 발견자의 확신, maintainer의 patch 수용, stable backport, CNA의 CVE·CVSS 결정은 서로 다른 증거 단계로 구분해야 합니다. mainline fix 2bb6379416fd · CVEProject 공식 레코드

최종적으로 남은 판단 원칙

Root 여부: namespace 안에서 uid 0이고 CAP_NET_ADMIN이 보인다는 사실만으로 host 또는 상속 netns 관리 권한이 생기지 않습니다. uid 숫자보다 capability가 어느 user namespace에 속하는지를 기준으로 판단합니다.

Open 권한: /dev/ppp open 단계의 권한 검사만으로 이후 ioctl이 안전하다고 볼 수 없습니다. open credential과 ioctl 시점의 target netns가 다를 수 있으므로 실제 object operation 직전에 대상 기준으로 검사해야 합니다.

관찰과 추론: runtime에서 실행한 관찰값, 공통 code path에 근거한 정적 판단, 아직 실행하지 않은 기대값을 문서에서 분리합니다.

호환성: 수정은 권한 없는 inherited target netns의 administrative ioctl을 차단하면서, target netns를 실제로 소유한 user namespace의 정상 권한은 유지하도록 설계해야 합니다. 다만 보존 증거에서 CASE B는 정적 기대값입니다.

Provenance: working tree, 전송 patch, build 결과와 QEMU log가 같은 revision을 가리키는지 확인한 뒤에만 제출 가능한 증거로 승격합니다.

영향과 수정

필요한 kernel 기능과 /dev/ppp 접근 전제가 충족된 환경에서 동적으로 확정한 영향은 로컬 비특권 사용자가 새 user namespace의 권한만으로 자신이 소유하지 않은 상속 network namespace에 PPP unit을 생성한 authorization bypass입니다. PPPIOCATTACH와 PPPIOCATTCHAN도 같은 unattached dispatch를 통과하므로 source-level 영향 범위에는 포함되지만, 기존 PPP session·channel 조작은 공개 PoC에서 end-to-end 실행하지 않았습니다.

Linux CNA의 CVSS 8.8과 C:H/I:H/A:H는 PPP control·frame injection·resource disruption 가능성에 대한 scoring scenario입니다. 공개 PoC가 세 영향을 모두 실증했거나 host root shell을 획득한 것은 아닙니다.

재현 및 실제 도달 전제

local code execution

CONFIG_USER_NS와 unprivileged user namespace 생성 허용

Linux PPP 기능 활성화와 /dev/ppp 존재·파일 권한 접근

container 환경에서는 device-cgroup 또는 동등한 device access 정책 허용

network namespace를 새로 만들지 않고 기존 target netns 상속

공개 PoC가 /dev/ppp를 직접 생성·chmod하는 부분은 최소 QEMU initramfs를 위한 privileged harness setup입니다. 실제 공격 환경에서는 공격자가 이미 접근 가능한 PPP device node가 있어야 합니다.

동적으로 확인한 범위

CLONE_NEWUSER만 사용해 기존 network namespace inode를 유지

취약 baseline d0c3bcd5b8976159d835a897254048e078f447e6에서 PPPIOCNEWUNIT 성공

v3 patch에서 동일 호출이 EPERM

정적으로 확인한 범위

PPPIOCNEWUNIT, PPPIOCATTACH, PPPIOCATTCHAN이 동일 unattached authorization gate를 공유

target netns의 owner user namespace에 대한 capability 검사 누락과 공통 fix

실행하지 않았거나 증명하지 않은 범위

PPPIOCATTACH·PPPIOCATTCHAN 별도 runtime fixture

new userns+new owned netns 정상 대조군 CASE B

임의 host root shell, host kernel code execution 또는 완성된 일반 LPE chain

모든 영향 버전에 대한 개별 QEMU 실행

⚠️

두 guest log 마지막의 Kernel panic - not syncing: Attempted to kill init!은 최소 initramfs에서 PID 1인 테스트 /init이 종료되며 발생한 harness 종료 artifact입니다. CVE의 kernel panic 영향이나 패치 실패 증거가 아닙니다. 판정은 panic 이전의 PPPIOCNEWUNIT succeeded와 EPERM 행을 기준으로 합니다.

수정

수정은 ppp_unattached_ioctl()의 switch 전에 ns_capable(net->user_ns, CAP_NET_ADMIN)을 검사해, capability를 실제 변경 대상인 network namespace의 owner user namespace에 연결합니다. mainline fix 2bb6379416fd

영향 및 최초 수정 버전

계열	최초 수정 버전
5.10	5.10.258
5.15	5.15.209
6.1	6.1.175
6.6	6.6.141
6.12	6.12.91
6.18	6.18.33
7.0	7.0.10
mainline	commit `2bb6379416fd` · official fixed version 7.1 (mainline)

취약 코드는 273ec51dd7ceaa76e038875d85061ec856d8905e에서 도입되어 Linux 2.6.30 계열부터 존재했습니다. 배포판 kernel은 version string보다 vendor backport/advisory 기준으로 판정해야 합니다. 전체 범위와 stable fix commit은 CVEProject 공식 레코드를 기준으로 합니다.

분석 기준과 증거 보존

항목	감사 결과
동적 baseline	`d0c3bcd5b8976159d835a897254048e078f447e6` 한 snapshot에서 QEMU 검증. 전체 영향 버전을 동적으로 실행한 것은 아님
수정 기준	v3 patch와 최종 upstream mainline commit `2bb6379416fd19f44c3423a00bfd8626259f6067`을 대조
동적 증거	동일 단일-process PoC에서 취약 kernel의 `PPPIOCNEWUNIT succeeded`와 v3 patched kernel의 `Operation not permitted`를 QEMU serial로 확인
정적 증거	세 unattached ioctl이 같은 dispatch와 공통 pre-switch capability gate를 공유함을 source와 patch에서 확인
GitHub 보존 상태	감사 commit `c04cacf`; evidence 8개, 사례별 SHA256SUMS와 root manifest의 size·SHA-256이 현재 파일과 일치
공식 CVE 레코드	보존 `cve-record.json`이 2026-08-31 현재 CVEProject JSON과 byte-identical
보존 경계	GitHub는 curated evidence archive이며 raw investigation session, 전체 build tree, initramfs·kernel binary, 원본 `.config`와 dirty diff는 제외
독립 재현 제약	두 guest kernel이 `-dirty`; tool/QEMU version과 vulnerable build driver log가 불완전하며 driver log의 patched 성공 체크리스트에 stale `PPPIOCNEWUNIT succeeded` 문구가 남아 있음
2026-08-23 감사 의미	원본 artifact·hash·link 대조와 GitHub push. 보존 QEMU log는 2026-04 실행 결과이며 8월 fresh rerun으로 해석하지 않음

🗂️

보존 경계: GitHub에는 원본 조사 세션 전체가 아니라 공개 가능한 PoC·patch·source snapshot·QEMU log·CVE record를 선별 보존했습니다. 원본 session과 공개 artifact 사이의 file-level provenance는 별도 내부 기록으로 관리해야 합니다.

발견 및 검증 계보

자동 후보 발견: namespace mismatch를 plausible_security_bug로 분류한 후보 생성 단계였습니다. 초기 분석은 후보일 뿐 실증이 아니었습니다.

로컬·QEMU 검증: 후속 조사에서 local source를 재검증하고 초기 harness 실패를 정정한 뒤, 유효 vulnerable/patched QEMU log와 v3 patch를 확보했습니다.

사후 CVE 연결: 원본 검증 시점에는 CVE ID가 아직 없었습니다. upstream merge와 stable 반영 뒤 Linux CNA가 CVE-2026-53075를 배정·공개했으며, 현재 CVE identity와 버전 범위는 공식 CVE record를 근거로 연결합니다.

✅

최종 보존 링크: evidence 8개 · SHA256SUMS · 소스 출처표 · 감사 commit c04cacf

느낀 점

kernel namespace 취약점에서는 ‘권한이 있다’는 문장이 불완전했습니다. 누가, 어떤 user namespace에서, 어느 network namespace의 객체에 대한 권한을 갖는지 세 좌표를 같이 적어야 했습니다.

이번 archive가 확정한 것은 CASE A의 PPPIOCNEWUNIT 취약 성공과 패치 후 차단입니다. security fix와 기능 회귀를 완전히 구분하려면 향후 CASE B와 PPPIOCATTACH·PPPIOCATTCHAN용 runtime fixture를 추가해야 합니다. 문서에서는 이미 실행한 관찰값, source-level 판단, 아직 실행하지 않은 기대값을 분리해야 합니다.