En regardant l'extrait de code, j'ai l'impression que ce n'est pas l'affectation qui provoque l'exploit.
C'est l'optimisation de gcc qui supprime la vérification if (!tun) return POLLERR;
Du coup, derrière, au lieu de sortir de la fonction, on se retrouve avec sk qui pointe vers l'adresse 0 + offsetof(tun, sk).
Et là, c'est le drame. Par exemple, si le socket et supprimé, c'est sk->sk_destruct(sk) qui est appelé, et donc si tu as mis la fonction qui va bien à l'adresse 0 + offsetof(tun, sk) + offsetof(sk, sk_destruct), tu deviens calife à la place du calife...
[^] # Re: Il me manque une piece du puzzle
Posté par neologix . En réponse à la dépêche Exploit local dans le noyau Linux 2.6.30. Évalué à 7.
C'est l'optimisation de gcc qui supprime la vérification
if (!tun) return POLLERR;Du coup, derrière, au lieu de sortir de la fonction, on se retrouve avec sk qui pointe vers l'adresse
0 + offsetof(tun, sk).Et là, c'est le drame. Par exemple, si le socket et supprimé, c'est
sk->sk_destruct(sk)qui est appelé, et donc si tu as mis la fonction qui va bien à l'adresse0 + offsetof(tun, sk) + offsetof(sk, sk_destruct), tu deviens calife à la place du calife...