Linux 7.3 randomise la pile dès l’entrée du syscall et consolide l’ASLR du noyau
Fusionnée cette semaine pour Linux 7.3, la refonte de la randomisation de pile menée par Thomas Gleixner déplace le calcul au point le plus précoce possible et unifie le code des architectures. Les mainteneurs de systèmes durcis ont une raison de surveiller cette fenêtre de fusion.
21 août 2026. Phoronix rapporte une refonte de la randomisation de pile fusionnée cette semaine dans le noyau Linux 7.3. Thomas Gleixner d’Intel en est l’auteur principal. Août 2026. Le noyau Linux 7.2 vient de sortir, et la fenêtre de fusion de la 7.3 accueille déjà les changements de durcissement.
Pour un mainteneur de système durci, l’histoire tient en une phrase : l’ASLR du noyau se joue au moment exact où la pile est initialisée, et pendant des années ce moment est arrivé trop tard sur plusieurs architectures.
La randomisation de pile, ce pilier discret de l’ASLR
L’Address Space Layout Randomization — l’ASLR — repose sur un principe simple : rendre imprévisibles les adresses mémoire d’un processus pour casser les exploits qui en supposent la constance. L’utilisateur la connaît surtout sous la forme de /proc/sys/kernel/randomize_va_space, qui commande la randomisation de la pile, du tas, des mmap et de l’exécutable.
La randomisation de la pile en est le maillon le plus sensible. À chaque entrée dans un syscall, le noyau ajoute un décalage aléatoire au pointeur de pile, afin que deux appels successifs ne posent pas leur pile à la même adresse. C’est ce qui complique la vie des attaques par dépassement de pile, du pivot de pile et des chaînes ROP qui s’appuient sur des adresses prévisibles.
Le problème n’est pas le principe, c’est son exécution. La randomisation était dispersée dans le code d’entrée bas niveau de chaque architecture, et à des points parfois incorrects — avant même que l’état du processeur ne soit établi.
Ce que Gleixner a consolidé
La refonte de Thomas Gleixner porte sur le code commun ainsi que sur PowerPC, LoongArch, RISC-V, s390 et x86/x86_64. L’objectif, formulé dans la pull request, est de « consolider la randomisation de pile pour le code d’entrée générique et les architectures qui l’utilisent ».
Le constat de départ est précis : la randomisation de pile à l’entrée du syscall était « dispersée dans le code d’entrée bas niveau propre à chaque architecture, et dans certains cas aux mauvais endroits, par exemple avant l’établissement de l’état, ce qui viole les contraintes de non-instrumentabilité de ce code ».
La correction intègre la randomisation directement dans les helpers génériques d’entrée, afin qu’elle soit invoquée « au point le plus précoce possible, juste après l’établissement de l’état », et convertit toutes les architectures qui utilisent cette entrée générique. Le bénéfice est double : la pile est randomisée avant qu’un seul mot de code instrumentable ne s’exécute, et la logique cesse d’être dupliquée en autant de variantes qu’il y a d’architectures.
# Vérifier l'état de la randomisation d'espace d'adressage
cat /proc/sys/kernel/randomize_va_space # 2 = pile + tas + mmap + exécutableUn second levier : pouvoir désactiver le SUD
La même série de fusions apporte un second changement orienté sécurité : rendre le Syscall User Dispatch — le SUD — désactivable proprement. Le SUD permet à un processus utilisateur d’intercepter des syscalls sélectionnés et de les rediriger vers un handler, un mécanisme utile aux émulateurs et aux sandbox, mais qui élargit aussi la surface d’attaque du noyau.
Deux points de contrôle font leur apparition : l’option de compilation CONFIG_SYSCALL_USER_DISPATCH pour le couper à la construction, et le paramètre runtime kernel.syscall_user_dispatch pour le piloter sans recompiler. Pour un profil de durcissement, c’est la possibilité de réduire la surface d’attaque d’une fonctionnalité qu’on n’utilise pas, au lieu de la subir.
# Désactiver Syscall User Dispatch au runtime sur un noyau 7.3
sysctl kernel.syscall_user_dispatch=0Pourquoi ce changement arrive maintenant
Le calendrier n’est pas anodin. Linux 7.2 est sorti en août 2026, et la fenêtre de fusion de la 7.3 — dont la sortie est attendue en fin d’année — est le moment où les changements de fond atterrissent. Le fait qu’une refonte de cette nature, qui touche au chemin d’entrée de chaque syscall, soit acceptée dans la fenêtre dit quelque chose de sa maturité : elle a été suffisamment relue pour toucher au code le plus sensible du noyau.
L’enjeu dépasse le cercle des mainteneurs. À chaque syscall, le décalage de pile est désormais appliqué au point le plus précoce, avant tout code instrumentable. Le bénéfice n’est pas spectaculaire en benchmark — la randomisation ne coûte quasiment rien en cycles — mais il se mesure en fenêtres d’opportunité fermées : un exploit qui comptait sur une pile prévisible pendant les premières instructions du syscall perd cette hypothèse.
Verdict
Si vous maintenez des systèmes durcis, ne changez rien en urgence : la refonte atterrira avec Linux 7.3, et vos distributions la porteront à leur rythme. Ce qui mérite votre attention, c’est la lecture : quand la 7.3 arrivera, vérifiez que vos profils de durcissement qui touchaient au SUD passent par les nouveaux contrôles — CONFIG_SYSCALL_USER_DISPATCH ou kernel.syscall_user_dispatch — plutôt que par des patchs ad hoc.
Si vous suivez le noyau de près, retenez la méthode autant que le résultat : un durcissement de sécurité gagne en fiabilité quand il quitte le code propre à chaque architecture pour rejoindre le chemin générique. C’est exactement le mouvement inverse de la fragmentation qui, elle, laisse des variantes divergentes et des trous selon l’architecture.
La règle à retenir : la sécurité du noyau se joue à des microsecondes près, au tout début d’un syscall. Déplacer la randomisation de pile « au plus tôt » n’est pas un détail cosmétique — c’est fermer la fenêtre où la pile était encore prévisible.