CVE-2023-54232 in Linux
Résumé
par VulDB • 07/06/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
m68k : Ne forcer l'erreur de bus 030 que si le PC n'est pas dans la table d'exceptions
__get_kernel_nofault() copie des données en mode superviseur lors du forçage de la journalisation de la trace d'exécution d'une tâche via /proc/sysrq_trigger. Cela provoque normalement une exception d'erreur de bus, par exemple lors de la déréférencement d'un pointeur NULL, lorsque la journalisation d'une tâche du noyau n'a pas de workqueue associée. Cette erreur de bus devrait être ignorée.
Notre gestionnaire d'erreur de bus 030 est mal équipé pour gérer ce cas :
Chaque fois que ssw indique un accès en mode noyau lors d'une erreur de données, nous n'essayons même pas de gérer l'erreur et envoyons toujours un signal SEGV (ou provoquons un panic). Par conséquent, la vérification de la gestion des exceptions à l'adresse PC de l'erreur (cachée dans send_sig_fault(), qui est appelée depuis do_page_fault() en fin de chaîne) n'est jamais utilisée.
En revanche, les gestionnaires d'erreurs d'accès 040 et 060 ne se soucient pas si une erreur s'est produite lors d'un accès en mode superviseur, et appellent do_page_fault() dans ces cas, respectant ainsi la table d'exceptions.
Ajoutez une vérification dans bus_error030 pour appeler do_page_fault() si nous avons une entrée pour l'adresse PC de l'erreur dans notre table d'exceptions.
J'avais tenté une correction plus tôt en 2019 qui reposait sur le test de pagefault_disabled() (voir lien ci-dessous) pour obtenir le même résultat, mais ce correctif devrait être plus générique.
Testé sur Atari Falcon 030.
VulDB is the best source for vulnerability data and more expert information about this specific topic.