GhostLock의 PD2229 (SM8475, 5.10.233 GKI) 익스플로잇 실패 요약

1. 취약점 및 디바이스 사실

1.1 CVE-2026-43499 (GhostLock) 기본 정보

영향받는 커널 범위:

• 2.6.39 ≤ Linux < 6.1.175 ✅ 영향받음
• 6.2 ≤ Linux < 6.6.140 ✅ 영향받음
• 6.7 ≤ Linux < 6.12.86 ✅ 영향받음
• 6.13 ≤ Linux < 6.18.27 ✅ 영향받음
• 6.19 ≤ Linux < 7.0.4 ✅ 영향받음
• Android GKI 5.10은 어떤 패치 브랜치에도 없음 → PD2229의 5.10.233 이론적으로 영향받음

1.2 PD2229 디바이스 실측

2. 이상적 익스플로잇 체인 vs PD2229 실제 진행 상황

2.1 NebuSec 원체인 (x86_64 / Pixel 10 성공)

1. KASLR 우회        → prefetch timing / PR_SET_MM_MAP auxv
2. UAF 트리거        → 3스레드 PI 의존성 교착 → FUTEX_CMP_REQUEUE_PI가 -EDEADLK 반환
3. 스택 재활용       → PR_SET_MM_MAP이 auxv를 waiter 스택 프레임에 복사
4. rb_erase 제한적 쓰기 → inet6_protos[IPPROTO_UDP] 덮어쓰기
5. CEA + ROP         → 제어 흐름 탈취
6. core_pattern 변조 → root shell (97% 성공률)

2.2 PD2229 각 단계 실제 진행 상황

3. 스택 재활용 프리미티브 전수 조사 결과 (PD2229 실측)

3.1 스택 프레임 레이아웃 핵심 계산

futex 경로 총 깊이:
  __arm64_sys_futex    0x90
  + do_futex           0xc0
  + futex_wait_requeue_pi  0x1b0
  = 0x300
waiter 위치 = SYS_SP - 0x300 + 0x20 = SYS_SP - 0x2e0

pselect 경로:
  core_sys_select 스택 프레임 0x1c0, stack_fds는 sp+0x50
  커버 구간: SYS_SP - 0x1c0 + 0x50 = SYS_SP - 0x170부터
  waiter (SYS_SP - 0x2e0)와의 차이 0x170 (368바이트) → 겹치지 않음

3.2 시도한 17가지 스택 쓰기 방법

17/17 전부 실패.

3.3 실패의 근본 원인

PD2229의 SM8475 5.10 GKI 컴파일러(PGO + LTO + BOLT)가 생성한 스택 레이아웃으로 인해 core_sys_select의 stack_fds와 futex_wait_requeue_pi의 rt_mutex_waiter가 구조적으로 겹치지 않는다. 이는 컴파일러가 결정한 객관적 사실이며, 익스플로잇 기법의 문제가 아니다.

JoinChang 저장소에 명시되어 있음: "The pselect stack overlay only works when the freed rt_mutex_waiter lands within the user-controllable region of the stack_fds buffer" — PD2229는 이 조건을 충족하지 않는다.

4. 공개 참조 저장소 비교 분석

NebuSec/CyberMeowfia — 원본 익스플로잇 프레임워크

• 저장소: https://github.com/NebuSec/CyberMeowfia
• 대상: x86_64 Linux / Pixel 10 (6.x GKI)
• 스택 재활용: PR_SET_MM_MAP이 auxv를 커널 스택에 복사
• 성공률: 97%, 약 5초 내 [root shell]
• PD2229 적용 가능성: ❌ PR_SET_MM_MAP이 Android에서 EPERM으로 차단됨

JoinChang/ghostlock-oneplus — OnePlus 잠금 해제 BL 탈옥

• 저장소: https://github.com/JoinChang/ghostlock-oneplus
• 검증된 디바이스:
  • OnePlus Ace 6T (PLR110, SM8845) — 6.12.38 GKI ✅
  • OnePlus 15 (PLK110, SM8845) — 6.12.23 GKI ✅
• 기술 요점:
  • 오프셋 자동 추출: kallsyms (28) + BTF (57) + 파생 (9) + 상수 (12) = 103/103
  • pselect 스택 오버레이, SP diff = -64
  • PSELECT_SHIFT = -2
  • 익스플로잇 체인: futex UAF → 위조 waiter → pselect로 스택 제어 → rb_erase 제한적 쓰기 → selinux_state.enforcing=0 → cred를 init_cred로 덮어쓰기
• 불가능 명시: "Not Feasible (stack layout incompatible)" — pselect stack_fds와 waiter가 겹치는 커널에만 적용 가능
• PD2229 적용 가능성: ❌ 커널 세대 불일치 (6.12 vs 5.10), 스택 레이아웃도 겹치지 않음

p2p3p/GhostLock-for-OnePlus — OnePlus 6.12 완전 익스플로잇

• 저장소: https://github.com/p2p3p/GhostLock-for-OnePlus
• 검증됨: OnePlus Ace 6T (SM8845, 6.12.38) ✅
• PD2229 적용 가능성: ❌ JoinChang과 동일, 커널 세대 불일치

YuKongA/ghostlock-oplus — OPPO Find N5/X8

• 저장소: https://github.com/YuKongA/ghostlock-oplus
• 커널: 6.6.118 GKI
• PD2229 적용 가능성: ❌ 커널 세대 불일치

OPPO Find X6 Pro (PGEM10) 적응 — 5.15.149

• 디바이스: SM8550, 5.15.149-android13, Android 15
• 진행 상황: ✅ KASLR 우회 (perf_event_open + callchain sampling); 이후 단계는 완전한 익스플로잇 미공개
• 의의: 5.15 GKI에서 KASLR 우회 가능을 증명했지만, 스택 재활용 단계는 공개 검증되지 않음

pubglite55/oppo-ghostlock — OPPO Find N2

• 저장소: https://github.com/pubglite55/oppo-ghostlock
• 디바이스: OPPO Find N2 (CPH2413, SM8475)
• 커널: 5.10.236-android12-9-o-g74d132f4467a
• Android: 16 (BP2A.250605.015)
• 구현 완료:
  • ✅ Firefox CVE-2026-10702 AAW (Stage 1)
  • ✅ KASLR bypass (kaslr_base 직접 계산)
  • ✅ GhostLock FUTEX 트리거 (FUTEX_CMP_REQUEUE_PI ret=0)
  • ✅ KernelSnitch mm_struct 누출
  • ✅ sk_buff 힙 스프레이 (4/4 send 성공)
  • ✅ IDA Pro 70+ 오프셋 검증
• 핵심 차단:

  "pselect가 waiter 구조를 조작할 수 없음 — NFDS >336일 때 fd_set이 힙에 있음; configfs/ashmem 미지원 (ashmem SET_NAME 잘림); 다른 모든 커널 쓰기 경로 차단됨 (/proc/self/mem, /dev/mem, binder)"

• PD2229 관계: 동일 플랫폼 동일 세대 (SM8475, 5.10.236 vs 5.10.233), 단 3개 마이너 버전 차이, 완전히 동일한 구조적 제약에 직면

harry1080/oppo-ghostlock — OPPO Find N2

• 저장소: https://github.com/harry1080/oppo-ghostlock
• 디바이스: OPPO Find N2 (CPH2413, SM8475)
• 커널: 5.10.236-android12-9-o-g74d132f4467a
• Android: 16 (BP2A.250605.015)
• 커뮤니티 공개 성명:

  "pixel10에서 익스플로잇 가능한 버전의 pselect stack_fds가 정확히 rt_waiter와 커널 스택에서 겹치는데, 이 부분이 실제로 가장 골치 아픈 곳이다. OPPO findN2 커널에서는 이 두 호출의 스택 부분이 완전히 겹치지 않거나, 겹쳐도 제어할 수 없다. 다른 제어 가능한 커널 스택 시스템 콜을 찾아 스택을 구성해야 하며, 단순히 오프셋을 적응시키는 것으로는 성공할 수 없다. oppo의 rt_waiter는 pselect stack_fds와 완전히 겹치지 않는다"

• PD2229 관계: PD2229와 동일하게 SM8475 5.10 GKI, 결론 완전히 적용 가능

4.3 참조 저장소 비교 총괄표

5. 핵심 커널 심볼 및 오프셋 (PD2229 vmlinux 실측)

정적 베이스 주소 0xffffffc008000000, 런타임 시 KASLR slide 추가 필요.

rt_mutex_waiter 구조체 (vivo 5.10.233 커스텀)

struct rt_mutex_waiter {
    uint64_t private;           // +0x00  (vivo 프라이빗 필드)
    struct rb_node {
        uint64_t rb_parent_color; // +0x08
        uint64_t rb_right;        // +0x10  (vivo 순서 변경)
        uint64_t rb_left;         // +0x18
    } tree;
    struct task_struct *task;   // +0x20
    struct rt_mutex *lock;      // +0x28
};
// 총 크기 0x30 (48바이트)

6. 구현 완료 vs 구현 필요

✅ 구현 완료된 인프라

1. KASLR 우회 — perf_event_open + callchain sampling (OPPO Find X6 Pro 5.15.149 방식과 동일)
2. UAF 트리거 — 3스레드 PI 교착, FUTEX_CMP_REQUEUE_PI가 -EDEADLK 반환
3. 완전한 심볼 테이블 — 103+ 심볼 IDA 검증 완료 (JoinChang의 103/103 추출 방법론 참조)
4. rt_mutex_waiter 구조체 레이아웃 — vivo 커스텀 오프셋 확인 완료
5. 스택 프레임 레이아웃 정밀 분석 — futex와 pselect/io_uring 경로 깊이 계산 완료
6. 17개 스택 재활용 후보 전수 배제 — 완전한 "불가능" 매트릭스 구축

❌ 미구현 (핵심 차단)

1. 스택 재활용 프리미티브 — SM8475 5.10 GKI 컴파일러 스택 레이아웃으로 인해 구조적으로 사용 불가
2. 제한적 쓰기 프리미티브 — 스택 재활용 실패로 rb_erase 트리거 불가
3. 이후 모든 단계 — 연쇄 차단

7. 최종 결론

⚠️ GhostLock (CVE-2026-43499)은 PD2229 (vivo X Fold+, SM8475, 5.10.233 GKI, Android 15 OriginOS 5)에서 익스플로잇 불가능.

근본 원인은 SM8475 5.10 GKI 컴파일러(PGO+LTO+BOLT)가 생성한 스택 레이아웃으로 인해 알려진 모든 syscall의 스택 프레임이 rt_mutex_waiter와 구조적으로 겹치지 않기 때문이다. 이는 컴파일러가 결정한 객관적 사실이며, 익스플로잇 기법의 문제가 아니다.

성공한 익스플로잇 사례는 모두 6.6/6.12 GKI인데, 이는 이러한 신형 커널의 컴파일러 출력이 pselect fd_set과 waiter를 완벽하게 겹치게 만들기 때문이다(SP diff=-64). 5.10 GKI는 이 조건을 갖추지 못한다.

구축 완료된 인프라

• ✅ KASLR 우회 프리미티브 (perf_event_open 사이드 채널)
• ✅ 103+ 커널 심볼 및 오프셋
• ✅ rt_mutex_waiter 구조체 레이아웃
• ✅ UAF 트리거 능력
• ✅ 17개 스택 재활용 후보 배제 매트릭스

9. 참조 저장소 인덱스