L'idée : realloc peut tout déplacer
Quand un tableau dynamique grandit, realloc peut le copier à une nouvelle adresse et libérer l'ancien bloc. Tout pointeur distribué vers l'ancien bloc est désormais pendant (dangling) : il pointe vers de la mémoire libérée.
Le lire est un use-after-free. Ça « marche » souvent encore, car la mémoire libérée n'est pas effacée tout de suite. C'est ce qui le rend dangereux.
La situation
store_open renvoie un Session * que les appelants conservent et utilisent plus tard, même après avoir ouvert d'autres sessions. Le tableau de sessions grandit avec realloc.
Votre mission
Lancez le sanitizer et lisez son rapport : où le bloc a été alloué, où il a été libéré, et quelle fonction l'a touché ensuite. Repensez ensuite la propriété pour que l'adresse d'une session ne change jamais, et expliquez précisément au junior comment faire.
À surveiller
- Agrandir énormément la capacité initiale ne fait que repousser le déplacement. Et après ?
- Modifier une struct, c'est aussi modifier le header, et la fonction qui libère tout.