CVE-2026-64468 — Use-after-free della durata del processo in binder_free_transaction() del kernel Linux

Questo repository contiene, per l'use-after-free del Binder del kernel Linux corretto dal commit upstream f223d27a546c1e1f48d38fd67760e78f068fe8c4:

• binder_chain_64468.c — una proof of concept non privilegiata che raggiunge il bug e lascia che il kernel lo dimostri, con un laboratorio KASAN e un confronto differenziale vulnerabile/corretto (lab/, run.sh, verify.sh).
• exploit.c — un'escalation di privilegi locale autonoma per x86_64. Si compila con gcc -O2 -pthread -o exploit exploit.c, viene eseguito come utente normale e termina in una shell di root.
• demo/ — un laboratorio che avvia un vero userland Debian 13 su un kernel non patchato, così che l'exploit possa essere compilato dal gcc della macchina di destinazione ed eseguito sulla macchina che poi prende il controllo.

Tutto viene eseguito come utente normale (uid/gid 1000, nessuna capability, nessun namespace) contro kernel upstream stock senza alcuna patch di alcun tipo.

Avviso

Questo codice fa deliberatamente gareggiare i tempi di vita degli oggetti del kernel e poi dirotta il flusso di controllo del kernel. Una gara persa corrompe lo stato dell'heap del kernel e può causare un panic o un blocco della macchina. Eseguilo solo in una VM isolata e usa e getta che possiedi. Non eseguirlo su un host.

Stato e ambito

Stato	Affermazione
Confermato	La vulnerabilità è reale, è raggiungibile da un processo non privilegiato e la correzione upstream la elimina.
Dimostrato	Il dereferenziamento vulnerabile di un binder_proc morente viene raggiunto naturalmente e ripetutamente sul kernel non patchato, e mai sul kernel corretto.
Dimostrato	L'use-after-free completo, segnalato da KASAN, sul kernel non patchato.
Dimostrato	Recupero del binder_proc liberato con byte controllati dall'attaccante, dirottamento del flusso di controllo del kernel ed escalation di privilegi a uid 0 da un utente non privilegiato, su x86_64.
Non affermato	Qualsiasi risultato su un dispositivo o vendor specifico. Sono stati testati solo i kernel upstream elencati di seguito, su x86_64.
Non affermato	Che l'exploit fornito funzioni senza modifiche contro un kernel di distribuzione. Vedi Quali sistemi sono interessati: richiede offset per-kernel e, su ogni distribuzione generica esaminata, il dispositivo binder non è raggiungibile da un utente non privilegiato in primo luogo.

Vulnerabilità

binder_free_transaction() legge il processo di destinazione dalla transazione sotto t->lock, rilascia quel lock e poi acquisisce il lock interno della destinazione:```c spin_lock(&t->lock); target_proc = t->to_proc; spin_unlock(&t->lock);

if (target_proc) {
	binder_inner_proc_lock(target_proc);   /* use after free */

Nothing keeps `target_proc` alive across that gap. A process that is being torn
down in parallel can reach `binder_proc_dec_tmpref() -> kfree()` in between, so
the lock is taken on freed memory. The upstream fix pins `t->to_thread` while
`t->lock` is still held, which keeps the owning process alive until the inner
lock has been used and released.

The vulnerability was reported by **Alice Ryhl** and fixed by **Carlos
Llamas**, both of Google. The
[original report](https://lore.kernel.org/all/[email protected]/)
carries the reference KASAN trace.

### Raggiungere l'accesso vulnerabile

L'unico chiamante che può raggiungere un `to_proc` *esterno* è
`binder_send_failed_reply()`, e attraversa `t->from_parent` solo quando
`t->from` è `NULL`:```c
	target_thread = binder_get_txn_from_and_acq_inner(t);
	if (target_thread) { ...; binder_free_transaction(t); return; }
	next = t->from_parent;
	binder_free_transaction(t);
	t = next;

from_parent viene assegnato in un unico punto, e l'assegnazione è protetta poche righe prima dal controllo di bad transaction stack del binder: un thread può inviare una transazione sincrona solo mentre la cima del suo stack è una transazione che sta ricevendo. Pertanto, per ogni anello di quella catena, il sender del figlio e il receiver del genitore sono lo stesso thread.

Questo ha una conseguenza netta. binder_thread_release() percorre lo stack del thread morente con proc->inner_lock acquisito e scrive entrambi i``` iteration j : [holds child->lock ] child->from = NULL ; unlock child->lock spin_lock(parent->lock) iteration j+1 : [holds parent->lock] parent->to_proc = NULL

in **iterazioni adiacenti di una singola walk**, ciascuna sotto il rispettivo
`t->lock`. Un walker apprende che `child->from == NULL` solo dopo che la walk ha rilasciato
`child->lock`, e necessita di `parent->lock` per la propria snapshot. Quindi l'intera
opportunità è il divario tra lo `spin_unlock(&child->lock)` di quella walk e il suo
`spin_lock(&parent->lock)` — un paio di istruzioni. La release walk mantiene uno
spinlock e non può essere preemptata lì; solo un interrupt può ritardarla.

Questo è il motivo per cui la race è ristretta e per cui sia la proof of concept che
l'exploit sono probabilistici.

### Cosa costruisce la proof of concept

`binder_chain_64468.c` costruisce la catena più corta che raggiunge
l'accesso vulnerabile, così il lavoro del walker all'interno di quel divario è il più piccolo
che binder consente — due acquisizioni di `t->lock` e una `kfree()`, senza
`inner_proc_lock` estraneo, senza `wake_up` e senza consegna di risposta:```
  B thread i   --e2 (sync, code 0x4442414b)-->  P thread Y_i
  P thread Y_i --e1 (sync, code 0x54414c4c)-->  B thread i   (nested target)

  B thread i   stack: [ e2 outgoing , e1 incoming (top) ]
  P thread Y_i stack: [ e2 incoming , e1 outgoing (top) ]

P quindi chiude il proprio fd del binder, così binder_deferred_release() rilascia Y_1..Y_K e infine libera il binder_proc, mentre ogni thread B emette contemporaneamente BINDER_THREAD_EXIT:``` binder_thread_release(B_i) nulls e1->to_proc (own proc) and e2->from binder_send_failed_reply(e1) e1->from == NULL once Y_i was released -> binder_free_transaction(e1) target_proc already NULL, kfree(e1) -> binder_free_transaction(e2) target_proc == P <-- vulnerable access

Un terzo processo è il binder context manager, usato solo per distribuire gli
handle di cui gli altri due hanno bisogno. `exploit.c` riutilizza esattamente questa costruzione.

### Due condizioni indipendenti

Un report KASAN richiede entrambe le condizioni:

* **l'accesso vulnerabile** — il walker deve acquisire `parent->lock` all'interno della
  finestra ristretta sopra, così da catturare un'istantanea di un `to_proc` ancora vivo; e
* **il free che atterra dentro la finestra** — il walker deve poi perdere la CPU
  tra il rilascio di `t->lock` e l'acquisizione del lock interno della vittima, e restarne lontano
  finché il rilascio differito non è terminato e ha liberato il `binder_proc`.