PT-2026-98582 · Linux · Linux

CVE-2026-97918

·

Publicado

2026-09-25

·

Atualizado

2026-09-25

Nenhuma

Não há classificações de severidade ou métricas disponíveis. Quando houver, atualizaremos as informações correspondentes na página.
In the Linux kernel, the following vulnerability has been resolved:
tracing: Undo the registration when enabling the histogram trigger fails
Commit 6f86bdeab633 ("tracing: Fix bad hist from corrupting named triggers list") described how a trigger that is registered but not on file->triggers ends up freed while still on the global named triggers list, and moved the registration down so that hist trigger enable() follows it immediately. One path still gets there. hist trigger enable() adds the trigger and takes it straight back out when the event cannot be enabled:
list add tail rcu(&data->list, &file->triggers);

update cond flag(file);

if (trace event trigger enable disable(file, 1) < 0) {
	list del rcu(&data->list);
	update cond flag(file);
	ret--;
}
so the list walk in hist unregister trigger() matches nothing, test stays NULL, and the ->free() that would call del named trigger() is skipped. out unreg falls through to out free, which frees the trigger anyway:
BUG: KASAN: slab-use-after-free in find named trigger+0xac/0xc0 Read of size 8 at addr ffff8880091d3160 by task init/1 find named trigger+0xac/0xc0 hist register trigger+0xc1/0xa00 event hist trigger parse+0x3146/0x6af0 event trigger write+0xce/0x160 Freed by task 69: kfree+0x154/0x420 trigger kthread fn+0xfd/0x160
Leave the trigger where hist unregister trigger() can find it and let that undo the registration, which is the only code that knows all of what cmd ops->init() took: the named list entry, the hist pad reference, the reference on the trigger a named histogram is shared with, and the copied cmd ops. It also pairs the failed trace event trigger enable disable(), whose sm ref and buffered event reference are otherwise left behind.
Since ->free() releases trigger data and, for a trigger that does not share its histogram, hist data with it, out unreg can no longer fall through to out free. For a trigger that does share, hist register trigger() has already destroyed the caller's hist data, so the fall-through was reading freed memory there as well.
Move the enable timestamps check in hist unregister trigger() above the ->free() call for the same reason: hist data does not outlive it once the trigger being removed is the one that owns it.
Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾

Identificadores relacionados

CVE-2026-97918

Produtos afetados

Linux