Il researcher californiano Paul Francis Nel, noto come MeisterLone, ha pubblicato un proof-of-concept (PoC) tecnico chiamato no_ctrl che dimostra una vulnerabilità kernel sulla console PlayStation 5.
Il PoC sfrutta una use-after-free (UAF) nello stack legato alla syscall fsc2h_ctrl, sfruttando una race condition multi-thread che permette di corrompere la memoria e, in casi fortunati, ottenere il controllo del return instruction pointer (RIP).
https://t.co/fi15UDKYwk yeah!! @master_s9 @TheWizWiki
— Alexander GB Jhon (@alexnderjh) November 13, 2025
Il lavoro si basa su una disclosure privata originata da TheFlow e prende la forma di un payload per il framework Y2JB: funziona sui firmware testati e dichiarati dall’autore (circa 4.03–10.40) ma si limita a provocare un crash intenzionale per finalità dimostrative e legali.
La dinamica tecnica è chiara e ripetibile: un thread (Thread 3) invoca fsc2h_ctrl con il comando CMD_RESOLVE e viene subito sospeso; il kernel memorizza un puntatore allo stack di quel thread senza invalidarlo correttamente.
Un altro thread nel frattempo provoca la deallocazione di quello stesso stack, creando la finestra UAF. Un “spray” controllato da un thread principale tenta di ri-allocare e riempire la regione di memoria freed con dati costruiti per sovrascrivere il return address.
Se il timing è favorevole, cosa che avviene solo in una percentuale limitata dei test, la corruzione può sovrascrivere l’indirizzo di ritorno e far saltare il flusso di esecuzione su gadget ROP prevedibili.
Nell’esperienza riportata dall’autore, circa il 20% delle esecuzioni raggiunge il controllo di RIP prima che il payload interrompa l’esecuzione con un crash (SIGSEGV), mostrando il potenziale ma non l’implementazione di un’eventuale escalation completa.
Descrizione tecnica della vulnerabilità
La vulnerabilità è un use-after-free (UAF) nello stack della syscall fsc2h_ctrl, una chiamata kernel usata per operazioni su filesystem e hardware controller (es. SD card o USB su PS5).
Il bug emerge da una race condition durante il comando CMD_RESOLVE: il kernel memorizza il puntatore allo stack di un thread, ma non gestisce correttamente la sospensione del thread, permettendo la liberazione prematura dello stack.
Questo crea una finestra temporale in cui lo stack freed può essere ri-allocato e corrotto (tramite “spray” di memoria), portando a UAF quando il thread riprende.
- Impatto potenziale: Controllo del RIP a un offset prevedibile (tipicamente basso, come
0x0000000000000000), abilitando una catena ROP per escalation di privilegi (es. da userland a kernel ring 0). In teoria, potrebbe chainare con tool come etaHEN per HENkaku o dump di memoria, ma il PoC non lo implementa, causa solo SIGSEGV e crash. - Condizioni trigger: Richiede timing preciso su 4 thread; i fallimenti (80% dei casi) avvengono durante lo spray o il ROP setup, dovuti a scheduler kernel imprevedibile.
- Mitigazioni Sony: Non patchato fino alla versione 10.40; firmware superiori (es. 11.xx-12.02 al 2025) potrebbero averla patchata, ma non confermato pubblicamente.
Meccanismo dettagliato della Race Condition
La race sfrutta il fatto che fsc2h_ctrl non invalida correttamente i puntatori sospesi, permettendo free durante la sospensione. Ecco il flusso esatto:
- Setup dello Slot (Thread 1): Occupa slot 0 della syscall con
CMD_WAIT, bloccando risorse e preparando il contesto per la race. Questo impedisce interferenze da altri processi. - Esecuzione CMD_RESOLVE (Thread 3): Il thread target invoca
fsc2h_ctrlconCMD_RESOLVE(comando per risolvere path o handle filesystem). Il kernel salva il puntatore allo stack corrente di Thread 3 nel contesto syscall. - Sospensione Immediata (Thread 3): Subito dopo,
thr_suspend_ucontextsospende Thread 3, congelando il suo execution state. Lo stack pointer resta “dangling” nel kernel—non free, ma pronto per corruzione. - Liberazione dello Stack (Thread 2): Durante la sospensione, Thread 2 invia un secondo
CMD_WAIT, che convince il kernel a free lo stack di Thread 3 (pensando sia idle). Questo crea l’UAF: lo stack è deallocato ma il puntatore kernel lo reference ancora. - Spray di Allocazioni (Main Thread): Il thread principale esegue un “spray” di allocazioni kernel (es. malloc-like per buffer piccoli), riempiendo la heap/stack freed con dati controllati. Punta a reclamare l’esatto indirizzo dello stack a un offset noto (basso, prevedibile su PS5).
- Ripresa e Trigger UAF (Thread 3): Riprendi Thread 3 con
thr_wakeupo simile. Al resume, il thread tenta di dereferenziare lo stack corrotto: il kernel processa il page fault sul UAF, portando a corruzione (es. overwrite di variabili locali o return address). - Controllo RIP e ROP Chain: La corruzione colpisce il return address stack, hijacking il flow a un gadget ROP prevedibile (es.
pop rdi; ret). Il PoC setuppa una chain parziale per demo, ma termina in crash invece di payload utile. - Cleanup/Fallimento: Se il timing fallisce (es. scheduler ritarda il free), crash prematuro durante spray. Successo: log
[7] resume t3 resume: 0x0000000000000000 waiting for t3 to return...+ crash.
Il tasso di successo (~20%) deriva dal timing race: su PS5, lo scheduler è deterministico ma influenzato da carico CPU. Test su emu o hardware reale mostrano varianze.
Ruoli dei Thread e sequenza in tabella
Per chiarezza, ecco i thread e la sequenza timed:
| Thread | Ruolo Principale | Azioni Sequenziali | Timing Critico |
|---|---|---|---|
| Thread 1 | Setup Slot | Chiama fsc2h_ctrl(CMD_WAIT) su slot 0 per occupare risorse. | Pre-race: Blocca slot. |
| Thread 3 | Target UAF | Chiama fsc2h_ctrl(CMD_RESOLVE) → Salva stack ptr → thr_suspend_ucontext(). | Durante: Sospensione <1ms. |
| Thread 2 | Free Trigger | Chiama fsc2h_ctrl(CMD_WAIT) per free stack di Thread 3. | Race window: Durante sospensione. |
| Main | Spray e Orchestrazione | Spray allocazioni → Resume Thread 3 → Monitora per ROP trigger. | Post-free: <100μs per reclaim. |
La sincronizzazione usa thr_create per spawnare thread e ksem_wait/post per signaling preciso.
Caratteristiche principali
- Tasso di Successo e Diagnostica: ~20% reach RIP control; log dettagliati tracciano fasi (es. “resume t3” per successo). Fallimenti: Crash su “timing ROP” o “spray region”.
- Compatibilità: Firmware 1.00-10.40 (testato su 10.20-10.40 per UAF privato). Non su 11.xx+ (potenzialmente patched).
- Integrazione Y2JB: Payload ELF per Y2JB v1.2 (github.com/Gezine/Y2JB)—carica via browser exploit (YouTube/LUA su FW 4.03-12.02). Richiede kernel iniziale da Lapse.js o simili.
- Output di Esecuzione: Su successo, termina con crash kernel (panic log visibile via UART); no dump o payload—solo demo UAF.
Istruzioni dettagliate per installazione e uso
La repo è raw (no release pre-build), scritto in C per toolchain PS5 (PSL1GHT/Orbis). Non plug-and-play, richiede dev setup.
- Prerequisiti: PS5 su firmware ≤10.40 con Y2JB v1.2 attivo (es. via YouTube app). Toolchain: PSL1GHT o PS5 SDK (github.com/PS5-Dev/ps5-sdk). Accesso UART opzionale per log.
- Clonare e compilare:
git clone https://github.com/MeisterLone/no_ctrl
cd no_ctrl
make # O usa orbis-ld per linkare come ELF payload
Dipendenze: libc PS5, syscalls headers da SDK.
- Integrazione Y2JB:
- Copiare
no_ctrl.elfin payload dir di Y2JB. - Avviare Y2JB via browser:
http://exploit-host-ps5.com(o host locale). - Trigger: Eseguire chain Y2JB → Carica payload su porta kernel.
- Copiare
- Esecuzione e Monitoraggio:
- Run su console: Y2JB injecta → Payload spawn thread.
- Log via UART: Cercare “[7] resume t3” per successo (~20% tentativi; riprova rebootando).
- Debug: Aggiungere
sceKernelDebugOutTextper trace personalizzati.
- Test Iterativi: Eseguire 5-10 run; se <20% successo, adatta timing (es. busy-loop per CPU affinity).
Download: Source code no_ctrl
Fonte: x.com
.){kind=link}