CVE-2026-97936 in Linux
Sumário
de VulDB • 25/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi corrigida:
tracing: Corrige corrupção de memória causada pelo modificador histograma/stacktrace
A função `parse_field()` define o flag `HIST_FIELD_FL_STACKTRACE` com base no modificador ".stacktrace" antes de procurar o nome do campo, e nada posterior verifica se o nome foi resolvido para um campo que armazena um stacktrace. A função `create_hist_field()` seleciona `HIST_FIELD_FN_STACK` apenas com base no ponteiro do campo, o que lê uma palavra `__data_loc` do registro e segue seus 16 bits menos significantes como um deslocamento (offset) dentro do mesmo registro.
A função `event_hist_trigger()` pega a primeira palavra ali como uma contagem de entradas (`n_entries`) e copia esse número de valores long em um array com 31 posições:
```c n_entries = *stack; memcpy(entries, ++stack, n_entries * sizeof(unsigned long)); ```
Nenhum dos extremos dessa cópia é limitado (bounded), e a contagem é o que quer que o evento armazene no deslocamento indicado, portanto qualquer campo serve:
# cd /sys/kernel/tracing/events/sched/sched_process_fork # echo 'hist:keys=parent_pid.stacktrace' > trigger # (true)
BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:rb_insert_color+0x18/0x130 timerqueue_linked_add+0x7e/0xd0 enqueue_hrtimer+0x39/0xb0 __hrtimer_run_queues+0x10f/0x1f0 </IRQ> RIP: 0010:memcpy+0xc/0x30 event_hist_trigger+0x165/0x690
A interrupção do timer ocorreu no rbtree que a cópia já havia ultrapassado. Nenhuma opção de depuração é necessária para isso; o KASAN relata a mesma gravação como uma leitura fora dos limites (out-of-bounds) de 13835058055416381440 bytes.
A documentação em `Documentation/trace/histogram.rst` já estabelece a regra: "deve ser um tipo long[]", portanto, ela deve ser aplicada assim que o nome for resolvido. Nomes que não resolvem para nenhum campo, como "hitcount.stacktrace" e os pseudo-campos comuns (`common_*`), são recusados pela mesma razão: eles não armazenam stacktraces a serem lidos.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.