CVE-2026-36355 : Realtek rtl819x Jungle SDK - Lecture/écriture non authentifiée de la mémoire du noyau via des ioctls de débogage

• CVE : CVE-2026-36355
• CWE : CWE-782, CWE-787, CWE-200
• Découvreur : Daniil Gordeev
• Divulgation : 2026-05-03

Résumé

Le pilote Wi-Fi du noyau rtl8192cd du « Jungle SDK » Realtek rtl819x (hors arborescence) expose deux ioctls — write_mem (0x89F5) et read_mem (0x89F6) - sans aucun contrôle d'accès. Tout utilisateur local capable d'ouvrir une interface réseau sans fil adossée à ce pilote peut lire ou écrire de la mémoire virtuelle arbitraire du noyau, ce qui mène directement aux privilèges root.

Les gestionnaires sont activés par _IOCTL_DEBUG_CMD_ dans 8192cd_cfg.h, qui est défini sans condition (pas de #ifdef DEBUG), de sorte que l'ensemble des commandes de débogage est compilé dans toutes les builds de production.

Un exploit de référence (kpwn) atteint uid=0 depuis un shell non privilégié, avec zéro adresse codée en dur — la disposition de task_struct et l'emplacement de init_task sont tous deux auto-détectés à l'exécution, ce qui le rend portable entre les versions du noyau et les builds OEM.

Produits concernés

La vulnérabilité se trouve dans le pilote Wi-Fi du noyau du Realtek rtl819x Jungle SDK, toutes versions connues jusqu'à la v3.4.14B. Aucun correctif au moment de la divulgation. Les rtlwifi / rtw88 / rtw89 du noyau Linux principal sont des bases de code différentes et ne sont pas concernés.

Le cœur de pilote partagé est compilé en plusieurs variantes (rtl8192cd, rtl8192es, rtl8192ee, rtl8192fe, rtl8188ee, etc.). Toute build du Jungle SDK incluant le pilote Wi-Fi est concernée.

Probablement concernés — vérification requise produit par produit

Le Realtek Jungle SDK est largement redistribué dans le cadre de contrats OEM. Les fournisseurs documentés dans la liste de fournisseurs de CVE-2021-35395 (qui ciblait un composant différent, dans l'espace utilisateur, du même SDK) incluent D-Link, TOTOLINK, Tenda, NEC, I-O DATA, Elecom, Buffalo, Humax, H3C et IP-COM. Pour savoir si chaque gamme de produits spécifique embarque le pilote noyau vulnérable, il faut examiner la version source GPL propre à chaque produit ; le présent avis ne l'affirme pas sans vérification indépendante.

Environnement de test

Confirmé : écriture de 0xDEADBEEF dans .bss du module, avec relecture et restauration ; élévation locale de privilèges complète de uid=1000 à uid=0 via le parcours de init_task et l'écrasement des credentials, depuis un shell non privilégié.

Détails techniques

Cause racine

Dans 8192cd_cfg.h :

#define _IOCTL_DEBUG_CMD_

Non protégé par #ifdef DEBUG. L'ensemble de commandes de débogage est livré dans chaque build de production.

Gestionnaires vulnérables

Le répartiteur rtl_ioctl() du pilote achemine 0x89F5 et 0x89F6 (dans la plage d'ioctls privés standard SIOCDEVPRIVATE+5/+6 utilisée par les pilotes sans fil pour les extensions constructeur) vers write_mem et read_mem. Les gestionnaires analysent une chaîne fournie par l'utilisateur :

• Lecture : dw,<addr>,<count> — lire count mots de 32 bits à l'adresse virtuelle du noyau addr
• Écriture : dw,<addr>,<count>,<value> — écrire count mots de 32 bits de value à addr

L'adresse est analysée avec _atoi(base 16), transmise à memcpy() dans l'espace d'adressage virtuel du noyau, puis le résultat est renvoyé à l'espace utilisateur via copy_to_user(). Aucun contrôle n'est effectué :

• ni contrôle capable()
• ni contrôle access_ok() sur l'adresse
• ni vérification des bornes sur la plage d'adresses
• ni verrouillage — les 59 ioctls du jeu de commandes de débogage partagent un unique tampon global de 2000 octets (tmpbuf1) dans .bss

La primitive de lecture est plafonnée à 128 octets par appel ; la primitive d'écriture accepte une longueur arbitraire.

La même lacune de contrôle d'accès s'applique aux autres gestionnaires de l'ensemble de débogage (lecture/écriture de registres matériels via 0x89F3/0x89F4/0x89F8–0x89FD, écritures MIB via 0x89F1, lecture/écriture eFuse, mode de test de fabrication). Ils sont atteignables par le même chemin de code et méritent un audit complet de la part de quiconque corrige ce bogue.

Preuve de concept

Exploit de référence kpwn.c (publié avec le présent avis) :

• S'exécute en tant qu'utilisateur non privilégié, sans avoir besoin de root.
• Auto-détecte les offsets de task_struct (comm, cred, tasks, pid) en parcourant init_task, lui-même localisé par balayage par force brute de .data du noyau.
• Auto-détecte l'interface vulnérable en sondant chaque /sys/class/net/* pour la primitive de lecture.
• 44 ioctls quand /proc/kallsyms est lisible, ~7600 ioctls quand kptr_restrict=2 (chemin de balayage complet de .data). Donne un shell root inconditionnellement à chaque exécution de test.

# Build:
arm-linux-gnueabi-gcc -static -O2 -o kpwn kpwn.c

# Run as unprivileged user:
$ id
uid=1000(pwn) gid=3003(inet) ...
$ /tmp/kpwn
kpwn — RTL8192CD kernel LPE
[*] Scanning interfaces...
[+] wlan0 — read primitive confirmed
[*] Resolving init_task...
[+] init_task @ 0xc08ecb38
[+] comm=0x3a8 cred=0x3a4 tasks=0x250 pid=0x2c0
[+] cred=0xed3a4500 uid=1000 gid=3003
[*] Overwriting credentials...
[+] uid=0 euid=0 gid=0 egid=0
*** GOT ROOT *** uid=1000 -> 0 (44 ioctls)
# id
uid=0(root) gid=0(root) groups=0(root)