CVE-2026-97921 in Linux
Zusammenfassung
von VulDB • 25.09.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
tracing: Freigabe des Histogramm-Felds, das aufgrund eines ungültigen Modifikators abgelehnt wurde
Das Schreiben eines hist-Triggers, dessen Wert oder Variable einen Modifikator enthält, der an dieser Stelle nicht zulässig ist, führt dazu, dass die dafür erstellten Felder nicht freigegeben werden (Memory Leak).
__create_val_field() übernimmt das Feld von parse_expr() und speichert es in hist_data->fields[], jedoch erst nachdem die Prüfungen für den Modifikator durchgeführt wurden:
hist_field = parse_expr(hist_data, file, field_str, flags, var_name, &n_subexprs); ... if (hist_field->flags & HIST_FIELD_FL_VAR) {
if (hist_field->flags & (...)) goto err; } else {
if (hist_field->flags & (...)) goto err; }
hist_data->fields[val_idx] = hist_field;
Beide Prüfungen springen an dieser Zuweisung vorbei, und die Fehlermarke „err“ kehrt zurück, ohne irgendetwas freizugeben. Der Fehler wird bis zu create_hist_data() hochgereicht, das destroy_hist_data() -> destroy_hist_fields() aufruft. Letztere Funktion erreicht ein Feld jedoch nur durch Durchlaufen von fields[]. Ein Feld, das diesen Pfad nie erreicht hat, ist nicht erreichbar (unreachable).
Das Commit e0213434fe3e („tracing: Do not let histogram values have some modifiers“) setzte ret auf -EINVAL und fiel in die Zuweisung hinein, wodurch das Feld im Besitz von fields[] verblieb und zusammen mit dem Rest von hist_data freigegeben wurde. Die Aufteilung der Prüfung in einen Wertfall und einen Variablenfall ersetzte dieses Durchfallen (Fall-through) durch ein goto, das es überspringt.
Mit CONFIG_DEBUG_KMEMLEAK hinterlassen 200 Schreibvorgänge von
# echo 'hist:keys=prev_pid:vals=next_pid.log2' > \ events/sched/sched_switch/trigger
jeweils korrekt mit -EINVAL abgelehnt, 332 nicht referenzierte Objekte (63744 Bytes), die in create_hist_field() gemeldet werden; 200 Installations- und Entfernungszyklen eines gültigen Triggers hinterlassen keine. Ein '.log2'-Feld besteht aus zwei Allokationen, da create_hist_field() das einfache Feld in operands[0] des log2-Felds platziert, und beide werden gemeldet.
Verwenden Sie destroy_hist_field() anstelle von __destroy_hist_field(), damit auch operands[0] freigegeben wird. Es kehrt frühzeitig für HIST_FIELD_FL_VAR_REF zurück, was erforderlich ist, wenn ein Operand im Besitz von hist_data->var_refs[] steht; das abgelehnte Feld selbst ist niemals eine var ref, da eine var ref nie ein Modifikator-Flag trägt.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.