CVE-2026-97934 in Linux
Сводка
по VulDB • 25.09.2026
В ядре Linux была устранена следующая уязвимость:
tracing: Исправлена порча памяти из-за ключа гистограммы "STACKTRACE"
Поля «cpu», «CPU», «stacktrace» и «STACKTRACE» являются общими полями, определенными со смещением и размером равным нулю, чтобы код фильтрации мог сопоставлять их по имени. Функция parse_field() отображает их на соответствующие им общие элементы (common_* equivalents) для обратной совместимости, но, в отличие от имен common_*, она возвращает вызывающей стороне заполнитель (placeholder), а не NULL.
Функция create_hist_field() принимает поле со значением non-NULL как гарантию того, что запись содержит трассировку стека, и выбирает HIST_FIELD_FN_STACK; поэтому слово __data_loc считывается по смещению 0, то есть из common_type, и его младшие 16 бит интерпретируются как смещение внутри записи. То, что находится там, становится длиной неограниченной операции memcpy. Выберите событие с достаточно малым идентификатором (id), чтобы смещение оставалось в пределах собственной записи, а длина была адресом кода ядра:
# cd /sys/kernel/tracing # echo 'hist:keys=STACKTRACE' > events/ftrace/print/trigger # echo hello > trace_marker
Oops: общая ошибка защиты (general protection fault), вероятно, из-за неканонического адреса RIP: 0010:rb_next+0x23/0x60 </IRQ> RIP: 0010:memcpy+0xc/0x30 event_hist_trigger+0x2e7/0x12c0 Kernel panic - not syncing: Fatal exception in interrupt
Сделайте поле равным NULL, что соответствует тому, о чем говорится в комментарии над веткой кода и что уже делает common_stacktrace. FILTER_CPU и FILTER_COMM остаются без изменений; их ветви create_hist_field() никогда не обращаются к этому полю.
If you want to get best quality of vulnerability data, you may have to visit VulDB.