CVE-2026-36355: Realtek rtl819x Jungle SDK - Lettura/Scrittura non autenticate della memoria del kernel tramite ioctl di debug

• CVE: CVE-2026-36355
• CWE: CWE-782, CWE-787, CWE-200
• Scopritore: Daniil Gordeev
• Divulgato: 2026-05-03

Sommario

Il driver Wi-Fi del kernel rtl8192cd nel "Jungle SDK" out-of-tree Realtek rtl819x espone due IOCTL — write_mem (0x89F5) e read_mem (0x89F6) - senza alcun controllo di accesso. Qualsiasi utente locale in grado di aprire un'interfaccia di rete wireless supportata dal driver può leggere o scrivere memoria virtuale arbitraria del kernel, portando direttamente a root.

Gli handler sono abilitati tramite _IOCTL_DEBUG_CMD_ in 8192cd_cfg.h, che è definito incondizionatamente (nessun #ifdef DEBUG), quindi il set di comandi di debug viene compilato in tutte le build di produzione.

Un exploit di riferimento (kpwn) raggiunge uid=0 da una shell non privilegiata, con zero indirizzi hardcoded - il layout di task_struct e la posizione di init_task vengono entrambi rilevati automaticamente a runtime, rendendolo portabile tra versioni del kernel e build OEM.

Prodotti interessati

La vulnerabilità risiede nel driver Wi-Fi del kernel Realtek rtl819x Jungle SDK, in tutte le versioni note fino alla v3.4.14B. Nessuna correzione al momento della divulgazione. I driver Linux mainline rtlwifi / rtw88 / rtw89 sono codebase diverse e non sono interessati.

Il core condiviso del driver viene compilato in molteplici varianti (rtl8192cd, rtl8192es, rtl8192ee, rtl8192fe, rtl8188ee, ecc.). Qualsiasi build Jungle SDK che includa il driver Wi-Fi è interessata.

Probabilmente interessati — richiedono verifica per singolo prodotto

Il Realtek Jungle SDK è ampiamente ridistribuito tramite contratti OEM. I vendor documentati nell'elenco dei vendor di CVE-2021-35395 (che riguardava un diverso componente userspace dello stesso SDK) includono D-Link, TOTOLINK, Tenda, NEC, I-O DATA, Elecom, Buffalo, Humax, H3C e IP-COM. Stabilire se ogni specifica linea di prodotto includa il driver del kernel vulnerabile richiede l'ispezione della release GPL per singolo prodotto; questo advisory non lo afferma senza una verifica indipendente.

Ambiente di test

Confermato: scrittura di 0xDEADBEEF nel .bss del modulo con rilettura e ripristino; completa escalation di privilegi locale da uid=1000 a uid=0 tramite scansione di init_task e sovrascrittura delle credenziali, da una shell non privilegiata.

Dettagli tecnici

Causa principale

In 8192cd_cfg.h:

#define _IOCTL_DEBUG_CMD_

Non è presente alcun #ifdef DEBUG. Il set di comandi di debug è incluso in ogni build di produzione.

Handler vulnerabili

Il dispatcher rtl_ioctl() del driver instrada 0x89F5 e 0x89F6 (nell'intervallo standard di IOCTL privati SIOCDEVPRIVATE+5/+6 usato dai driver wireless per le estensioni del vendor) verso write_mem e read_mem. Gli handler analizzano una stringa fornita dall'utente:

• Lettura: dw,<addr>,<count> — legge count parole a 32 bit dall'indirizzo di memoria virtuale del kernel addr
• Scrittura: dw,<addr>,<count>,<value> — scrive count parole a 32 bit di value all'indirizzo addr

L'indirizzo viene analizzato con _atoi(base 16), passato a memcpy() sullo spazio di indirizzi virtuali del kernel e il risultato viene restituito con copy_to_user(). Non sono presenti:

• Nessun controllo capable()
• Nessun controllo access_ok() sull'indirizzo
• Nessun controllo dei limiti sull'intervallo di indirizzi
• Nessun blocco — tutti i 59 IOCTL del set di comandi di debug condividono un unico buffer globale di 2000 byte (tmpbuf1) in .bss

La primitiva di lettura è limitata a 128 byte per chiamata; la primitiva di scrittura accetta una lunghezza arbitraria.

La stessa mancanza di controllo degli accessi si applica ad altri handler del set di debug (lettura/scrittura dei registri hardware via 0x89F3/0x89F4/0x89F8–0x89FD, scritture MIB via 0x89F1, lettura/scrittura eFuse, modalità di test di produzione). Sono raggiungibili tramite lo stesso percorso di codice e richiedono un audit completo da parte di chi corregge questo bug.

Prova di concetto

Exploit di riferimento kpwn.c (pubblicato insieme a questo advisory):

• Viene eseguito come qualsiasi utente non privilegiato, non serve root.
• Rileva automaticamente gli offset di task_struct (comm, cred, tasks, pid) scorrendo init_task, che a sua volta viene individuato tramite scansione brute-force del .data del kernel.
• Rileva automaticamente l'interfaccia vulnerabile sondando ogni /sys/class/net/* per la primitiva di lettura.
• 44 IOCTL quando /proc/kallsyms è leggibile, ~7600 IOCTL quando kptr_restrict=2 (percorso di scansione completa del .data). Produce una shell di root incondizionatamente a ogni esecuzione del 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)