CVE-2026-97934 in Linux
Résumé
par VulDB • 25/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
tracing : Correction de la corruption mémoire due à une clé d'histogramme « STACKTRACE »
« cpu », « CPU », « stacktrace » et « STACKTRACE » sont des champs génériques, définis avec un décalage (offset) et une taille nuls afin que le code du filtre puisse les associer par leur nom. parse_field() les mappent sur leurs équivalents common_* pour assurer la compatibilité ascendante, mais contrairement aux noms common_*, ils renvoient au caller un pointeur placeholder non NULL plutôt qu'un pointeur NULL.
create_hist_field() prend un champ non-NULL comme garantie que l'enregistrement contient une trace de pile (stacktrace) et sélectionne HIST_FIELD_FN_STACK ; ainsi, le mot __data_loc est lu à partir du décalage 0, c'est-à-dire depuis common_type, et ses 16 bits de poids faible sont suivis en tant qu'offset dans l'enregistrement. Ce qui y est trouvé devient la longueur d'un memcpy non borné (unbounded). Choisissez un événement dont l'id est suffisamment petit pour que le décalage reste à l'intérieur de son propre enregistrement et que la longueur soit une adresse du texte noyau :
# cd /sys/kernel/tracing # echo 'hist:keys=STACKTRACE' > events/ftrace/print/trigger # echo hello > trace_marker
Oops : fault général de protection, probablement pour une adresse non canonique RIP : 0010:rb_next+0x23/0x60 </IRQ> RIP : 0010:memcpy+0xc/0x30 event_hist_trigger+0x2e7/0x12c0 Kernel panic - not syncing : Exception fatale dans l'interruption
Laissez le champ à NULL, ce que la commentaire au-dessus de la branche indique que le code fait et ce que common_stacktrace effectue déjà. FILTER_CPU et FILTER_COMM sont laissés tels quels ; leurs branches create_hist_field() ne consultent jamais le champ.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.