CVE-2025-21479 – Reproduction : root temporaire sur vivo iQOO 11 Pro (PD2254)

Recherche de sécurité autorisée sur un appareil personnel. CVE-2025-21479 est une vulnérabilité du GPU Qualcomm Adreno publique, corrigée (2025-08) et inscrite au catalogue CISA KEV. Ce document décrit l'intégralité du processus et de la livraison finale de la reproduction d'un root temporaire sur iQOO 11 Pro.

1. Aperçu de la vulnérabilité

• CVE : CVE-2025-21479 (CVSS 8.6, CWE-863 Incorrect Authorization)
• Composant : firmware GPU Qualcomm Adreno (a740_sqe.fw)
• Cause racine : défaut de condition de filtrage de l'instruction microcode and $04, $12, 0x3 du firmware v675 (0x7 dans la version corrigée), permettant aux flux de commandes en espace utilisateur de contourner les vérifications de permissions et d'exécuter des opérations GPU privilégiées (détournement des tables de pages SMMU), aboutissant à des lectures/écritures arbitraires en mémoire physique
• Impact : série Adreno A7xx (Snapdragon 8 Gen 1/2/3, etc.)
• Correctif : bulletin Qualcomm 2025-06 / correctif de sécurité Google 2025-08 (firmware v676+)

2. Appareil cible

Le firmware Android 16 (16.3.10.1) est corrigé ; cette reproduction ne s'applique qu'à Android 15 (15.2.12.2).

3. Sources de la reproduction

• zhuowei/cheese (Quest 3/3S, Adreno 740)
• ma4the/omae-wa-cheese-da (Galaxy Z Flip5, SM8550/Adreno 740 v675)

4. Travail de portage

4.1 Vérification de la disponibilité de la vulnérabilité (hors ligne)

• Extraction de a740_sqe.fw depuis le paquet OTA complet : 75 380 octets, le motif d'instruction vulnérable 0300 422a (and $04,$12,0x3) présente 3 occurrences → non corrigé
• Dans le paquet Android 16, ce motif est absent du même fichier → corrigé

4.2 Extraction des artefacts du noyau (hors ligne)

• boot.img → kernel.raw → restauration des symboles via vmlinux-to-elf
• Symboles clés : _text=0xffffffc008000000, _stext=0xffffffc008010000, swapper_pg_dir, selinux_state, init_task
• Décalages des structures BTF (task_struct / mm_struct / cred)
• Vérification KASLR : le _stext physique est fixé à 0xa8010000 (PHYS_OFFSET=0xA8000000, disposition standard SM8550), vérifié côté VMLINUX à 0xffffffc008010000

4.3 Points de portage clés (par rapport à omae-wa-cheese-da)

1. Constantes KASLR : les adresses virtuelles de swapper_pg_dir / init_task / selinux_state sont remplacées par les valeurs A15
2. Contournement de SELinux : écriture physique de selinux_state.enforcing=0. Il a été vérifié que le noyau A15 du PD2254 possède CONFIG_SECURITY_SELINUX_DEVELOP=y (présence dans kallsyms de sel_write_enforce/enforcing_setup), enforcing_enabled() lit le champ à l'exécution → l'écriture est effective, getenforce affiche Permissive
3. Adaptation des candidats du GPU spray (critique) : les candidats Samsung (0xbe..-0xfe..) tombent dans la zone réservée des appareils vivo de 2-4 Go ; au-delà de 4 Go (0x100000000), une faute SMMU GPU déclenche un redémarrage. Stratégie combinée = cluster validé 0xfebeb000 + candidats proches en 2-4 Go + candidats épars en zone haute 5-11 Go → taux de réussite nettement amélioré
4. Mise en place du root (caps-only, parade centrale contre l'anti-root de vivo) : vr.ko de vivo (module intégré dans vendorboot) utilise des hooks kprobe/tracepoint + un thread de surveillance pour tuer tout processus uid=0, avec en plus un auto-masquage du module et une vérification vermagic. Par conséquent, on ne met pas uid à zéro ; on réécrit physiquement les bits de capability des cred (uid conservé à 2000 + toutes les caps + PR_SET_KEEPCAPS/) → conservation de l'ensemble complet des capacités à travers exec, équivalent à root, sans déclencher le watchdog

5. Résultats de la validation (sur appareil réel)

Journal de réussite (premier passage, appareil initialement en Enforcing, chemin d'écriture physique d'enforcing) :

phyaddr: 0xfebeb000 (attempt 1/27)        # spray 候选命中
GPU R/W ready                             # 任意物理读写建立
found _stext at 0xa8010000                # KASLR 泄漏（扫描路径；显式 CHEESE_STEXT_PA 时无此行）
FW symbols resolved
stext = 0xa8010000                        # 物理 _stext = VA - 0xffffffc000000000 + 0xA8000000
SELinux enforcing overwrite verified (readback=1 enforce=0)
self creds: full caps granted (uid=2000 kept, watchdog dodge)
root shell (uid=2000, full caps kept)...

Si on l'exécute une seconde fois dans la même session (SELinux déjà en mode permissif), cette ligne devient SELinux already permissive.

6. Utilisation

# 设备刷入 Android 15 (15.2.12.2) 后：
adb push cheese /data/local/tmp/
adb shell chmod 755 /data/local/tmp/cheese
adb shell CHEESE_STEXT_PA=0xa8010000 /data/local/tmp/cheese
# 完成后当前 adb shell 会话即为 root shell（uid=2000 + 全 caps），SELinux 宽容模式

Variables d'environnement :

Nouvelles tentatives automatiques : bash cheese_auto.sh (exécution en boucle, détection des redémarrages hors ligne, écriture des journaux sur disque).

7. Précautions

• Root temporaire : à réexécuter après chaque redémarrage ; SELinux revient en mode Enforcing
• Le GPU spray est probabiliste : en cas d'échec, il suffit de réessayer (taux de réussite élevé dès la première passe avec les candidats combinés)
• Certains candidats en zone haute peuvent déclencher une faute GPU et redémarrer l'appareil (sans danger, nouvelle tentative automatique après redémarrage)
• Limite connue : vr.ko de vivo tue les processus uid=0 et le module s'auto-masque ; ni persistance ni intégration KernelSU n'ont été réalisées (le module KernelSU ne peut pas être chargé via insmod car le noyau n'exporte pas les symboles, voir l'annexe)
• À utiliser uniquement pour de la recherche de sécurité autorisée sur des appareils personnels

8. Liste des fichiers

• cheese : artefact compilé (ELF Android aarch64, NDK r28, livraison binaire, code source non public)
• cheese_auto.sh : script de nouvelles tentatives automatiques
• README.md : ce document

Annexe : mécanisme anti-root de vivo (vr.ko)

• Source : lib/modules/5.15-gki/vr.ko dans vendorboot.img (389 Ko)
• Mécanisme : hooks kprobe / tracepoint + thread de surveillance, qui surveille et tue les processus uid=0 ; auto-masquage après chargement, rmmod inopérant
• Conclusion de la contre-mesure : le setuid normal, la modification physique de cred uid=0 et l'héritage par les processus enfants sont tous tués → la seule voie stable est caps-only (uid≠0 + toutes les caps)

Avertissement

Ce dépôt est destiné uniquement à la recherche en sécurité et à des fins éducatives ; tous les tests ont été réalisés sur des appareils personnels de l'auteur. Veuillez l'utiliser dans le cadre d'une autorisation légale. L'utilisateur assume l'ensemble des risques.