Partie 21 - Les large bins - mécanismes de protection (2/2)

Les large bins : mécanismes de protection (2/2)

Protections selon les versions

• 2.3.4 : Safe Unlink : mise en place d’une vérification de l’intégrité des liens lors du retrait d’un bloc libre (unlink). La glibc vérifie alors que les pointeurs du bloc ciblé (victim) sont cohérents avec ceux de son prédécesseur et de son successeur ;
• 2.21 : Vérification des liens fd_nextsize et bk_nextsize (lorsqu’ils existent) du bloc à retirer ;
• 2.26 : Contrôle de la taille du bloc victim à retirer via prev_size lors de l’exécution de unlink.

Comme la fonction unlink peut être utilisée aussi bien pour des blocs provenant d’une small bin que d’une large bin, les protections ajoutées lors de la version 2.3.4 (Safe unlink) et 2.26 ont déjà été expliquées dans le chapitre concernant les protections ajoutées aux small bins.

Version 2.21 - Vérification des liens fd_nextsize et bk_nextsize du bloc à retirer

❌ Message d’erreur associé : corrupted double-linked list (not small).

Cette vérification ne s’applique, évidemment, qu’aux blocs qui disposent des champs fd_nextsize et bk_nextsize à savoir les premiers blocs de chaque taille.

Détails de la vérification

La vérification, présente dans la fonction unlink, est la suivante :

if (!in_smallbin_range (chunksize_nomask (p)) && p->fd_nextsize != NULL)
{
  if (p->fd_nextsize->bk_nextsize != p || p->bk_nextsize->fd_nextsize != p)
		malloc_printerr ("corrupted double-linked list (not small)");
/*
(...)
*/
}

Je vous propose de voir un exemple pratico-pratique afin de comprendre ce qui est comparé, même si je suis persuadé que vous avez compris du premier coup 😉. Imaginons que 4 blocs de tailles 0x400, 0x410, 0x420 et 0x430 soient libérés. Ensuite, une allocation de taille 0x410 est réalisée.

Voici, en 🟡, ce qui sera vérifié lors de l’appel à unlink (en plus des précédentes vérifications) :

Le bloc victim (ou p) est évidemment le bloc en 🔵.