CVE-2026-64468 — Use-after-free de durée de vie de processus dans binder_free_transaction() du noyau Linux

Ce dépôt contient, pour le use-after-free du Binder du noyau Linux corrigé par le commit amont f223d27a546c1e1f48d38fd67760e78f068fe8c4 :

• binder_chain_64468.c — une preuve de concept sans privilèges qui atteint le bug et laisse le noyau le prouver, avec un laboratoire KASAN et une différentielle vulnérable/corrigé (lab/, run.sh, verify.sh).
• exploit.c — une élévation de privilèges locale autonome pour x86_64. Elle se compile avec gcc -O2 -pthread -o exploit exploit.c, s'exécute en tant qu'utilisateur ordinaire et aboutit à un shell root.
• demo/ — un laboratoire qui démarre un véritable userland Debian 13 sur un noyau non corrigé, afin que l'exploit puisse être compilé par le gcc propre à la cible et exécuté sur la machine qu'il prend ensuite en main.

Tout s'exécute en tant qu'utilisateur ordinaire (uid/gid 1000, sans capacités, sans espaces de noms) contre des noyaux amont standard sans aucun correctif.

Avertissement

Ce code fait délibérément la course sur les durées de vie des objets du noyau, puis détourne le flux de contrôle du noyau. Une course perdue corrompt l'état du tas du noyau et peut provoquer un panic ou un blocage de la machine. Exécutez-le uniquement dans une VM isolée et jetable qui vous appartient. Ne l'exécutez pas sur un hôte.

État et portée

État	Affirmation
Confirmé	La vulnérabilité est réelle, est atteignable depuis un processus sans privilèges, et le correctif amont la supprime.
Démontré	La déréférence vulnérable d'un binder_proc mourant est atteinte naturellement et de manière répétée sur le noyau non corrigé, et jamais sur le noyau corrigé.
Démontré	Le use-after-free complet, signalé par KASAN, sur le noyau non corrigé.
Démontré	La récupération du binder_proc libéré avec des octets contrôlés par l'attaquant, le détournement du flux de contrôle du noyau, et l'élévation de privilèges vers uid 0 depuis un utilisateur sans privilèges, sur x86_64.
Non affirmé	Tout résultat sur un appareil ou un fournisseur spécifique. Seuls les noyaux amont listés ci-dessous ont été testés, sur x86_64.
Non affirmé	Que l'exploit fourni fonctionne sans modification contre un noyau de distribution. Voir Quels systèmes sont concernés : il nécessite des décalages propres à chaque noyau, et sur chaque distribution à usage général examinée, le périphérique binder n'est de toute façon pas accessible à un utilisateur sans privilèges.

Vulnérabilité

binder_free_transaction() lit le processus cible depuis la transaction sous t->lock, relâche ce verrou, puis acquiert le verrou interne de la cible :```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 */

Rien ne maintient `target_proc` en vie à travers cet intervalle. Un processus en cours de démantèlement
en parallèle peut atteindre `binder_proc_dec_tmpref() -> kfree()` entre les deux, de sorte
que le verrou est pris sur de la mémoire libérée. Le correctif en amont épingle `t->to_thread` pendant que
`t->lock` est toujours détenu, ce qui maintient le processus propriétaire en vie jusqu'à ce que le
verrou interne ait été utilisé et libéré.

La vulnérabilité a été signalée par **Alice Ryhl** et corrigée par **Carlos
Llamas**, tous deux de Google. Le
[rapport original](https://lore.kernel.org/all/[email protected]/)
contient la trace KASAN de référence.

### Atteindre l'accès vulnérable

Le seul appelant qui peut atteindre un `to_proc` *étranger* est
`binder_send_failed_reply()`, et il ne parcourt `t->from_parent` que lorsque
`t->from` est `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 est assigné à un seul endroit, et cette assignation est protégée quelques lignes plus tôt par la vérification de la pile de transactions invalide du binder : un thread ne peut envoyer une transaction synchrone que si le sommet de sa pile est une transaction qu'il est en train de recevoir. Par conséquent, pour chaque maillon de cette chaîne, l'émetteur de l'enfant et le récepteur du parent sont le même thread.

Cela a une conséquence majeure. binder_thread_release() parcourt la pile du thread mourant avec proc->inner_lock maintenu, et écrit à la fois``` 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

dans **les itérations adjacentes d’une même marche**, chacune sous le
`t->lock` correspondant. Un marcheur ne découvre `child->from == NULL` qu’une fois que la marche a libéré
`child->lock`, et a besoin de `parent->lock` pour sa propre capture instantanée. Toute l’opportunité réside donc dans l’intervalle entre le `spin_unlock(&child->lock)` de cette marche et son
`spin_lock(&parent->lock)` — quelques instructions. La marche de libération détient un
spinlock et ne peut pas être interrompue par une préemption à cet endroit ; seule une interruption peut la retarder.

C’est pourquoi la course est étroite et pourquoi tant la preuve de concept que l’exploit sont probabilistes.

### Ce que construit la preuve de concept

`binder_chain_64468.c` construit la chaîne la plus courte qui atteint l’accès vulnérable, afin que le travail du marcheur dans cet intervalle soit aussi réduit que binder le permet — deux acquisitions de `t->lock` et un `kfree()`, sans `inner_proc_lock` étranger, sans `wake_up` et sans remise de réponse :```
  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 abandonne ensuite son fd de binder, de sorte que binder_deferred_release() libère Y_1..Y_K et finit par libérer le binder_proc, tandis que chaque thread B émet simultanément 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 troisième processus est le gestionnaire de contexte du binder, utilisé uniquement pour distribuer les
handles dont les deux autres ont besoin. `exploit.c` réutilise exactement cette construction.

### Deux conditions indépendantes

Un rapport KASAN nécessite les deux éléments suivants :

* **l'accès vulnérable** — le parcoureur doit prendre `parent->lock` dans la
  fenêtre étroite ci-dessus, afin de capturer un `to_proc` encore vivant ; et
* **l'atterrissage de la libération dans la fenêtre** — le parcoureur doit ensuite perdre son CPU
  entre la libération de `t->lock` et la prise du verrou interne de la victime, et rester hors de celui-ci
  jusqu'à ce que la libération différée soit terminée et ait libéré le `binder_proc`.