Bonjour,
Administrateur de serveurs sous Debian je suis confronté, à chaque mise à jour impactant le noyau, à un problème de taille : dois-je rebooter 
Pour élucider cette question je consulte plusieurs sources afin de connaitre l’impact de la mise à jour.
Je vous propose de vous donner quelques tuyaux en prenant l’exemple de la faille CVE-2016-0728 qui est pour ce cas une faille majeure impactant les noyaux > 3.8. Pour info, je me base sur la version stable du moment (Jessie) dans mes explications.
Une des premières pistes est de configurer votre gestionnaire de paquet afin qu’il vous affiche les changelogs. Pour cela le mieux est de faire un tour par le paquet apt-listchanges. Paquet sur lequel je ne m’attarderais pas, car sa doc est très bien faite.
man apt-listchangesLe changelog a dans mon cas permis de récupérer le numéro identifiant la faille.
KEYS: Fix keyring ref leak in join_session_keyring() (CVE-2016-0728)Etant donné que le changelog n’est pas bavard j’ai commencé mon investigation.
Tout d’abord, le site https://security-tracker.debian.org/tracker/CVE-2016-0728 m’a permis de connaitre les versions de debian impactées et surtout les noyaux dans mon cas.
Grâce à un uname –a j’ai pu voir la version de mon noyau qui … est vulnérable 
jessie 3.16.7-ckt11-1+deb8u3 vulnerableJe peux aussi voir que le dépôt sécurité contient la mise à jour
jessie (security) 3.16.7-ckt20-1+deb8u3 fixedCe qu’il faut savoir, c’est que chaque mise à jour critique de noyaux ne me concerne pas forcement, car celle-ci peux être pour un module désactivé ou non utilisé sur mon noyau.
Pour avoir encore plus d’information on peut aller directement voir sur les logs du git du noyau linux https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/ et faire une recherche avec le numéro de la faille.
Ce qui me permet de trouver un changelog plus précis, et dans ce cas avec même un bout de code permettant de tester la présence de la faille sur une machine vulnérable https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=23567fd052a9abb6d67fe8e7a9ccdd9800a540f2
Attention, le script donner peut nuire à la stabilité du noyau, évité de le lancer sur une machine de PROD.
Ici on peut voir que la faille vient toucher les clés de session utilisateur permettant une escalade de privilège. La faille est donc bien critique et me concerne car elle touche un élément du noyau que j’utilise. De plus, au vu de l’impact sur le noyau et ne possédant pas de noyau patchable à chaud, je devrais surement passer par un reboot
Pour aller plus loin on peut aussi aller voir sur les logs du git Debian dédié au noyau pour voir s’ils ont bien pris en compte le correctif https://anonscm.debian.org/cgit/kernel/linux.git/log/
En se plaçant sur la branche jessie-security https://anonscm.debian.org/cgit/kernel/linux.git/log/?h=jessie-security
On peut voir le log concernant l’enregistrement de la faille avec tous les détails trouvés précédemment https://anonscm.debian.org/cgit/kernel/linux.git/commit/?h=jessie-security&id=0ac8c3e88cf1ea329ede357f2a01a9b1a8734e24
Et on peut aussi voir son avancement dans un deuxième log https://anonscm.debian.org/cgit/kernel/linux.git/commit/?h=jessie-security&id=5c6e7b5fbe9e5e5b3ae978c5a1aa049e9b464de3
-linux (3.16.7-ckt20-1+deb8u3) UNRELEASED; urgency=medium
+linux (3.16.7-ckt20-1+deb8u3) jessie-security; urgency=high
Log ou on voit qu’il est disponible dans le dépôt security et qu’il ne sera pas déployé pour le dépôt Jessie ce qui est normal.
Et donc pour finir j’ai finalement déployé le patch sur mon serveur
apt-get update && apt-get upgradeEt en faisant un uname –a, ne voyant pas la version patché (3.16.7-ckt20-1+deb8u3) déployé cela confirme la nécessité d’un reboot
J’ai donc finis par planifier un reboot via un Cron pour cette nuit afin de ne pas impacter la PROD.
Voila 
j’espère en aider quelqu’un dans leurs recherches, et si certains d’entre vous on d’autre tuyaux vous êtes les bienvenus 
N’hésiter par à me corriger si jamais j’ai dit une grosse connerie 
Et bon reboot à tous 
