CVE-2026-97919: tracing: Take the reference before publishing the named histogram trigger
In the Linux kernel, the following vulnerability has been resolved:
tracing: Take the reference before publishing the named histogram trigger
eventhisttriggernamedinit() puts the trigger on the global namedtriggers list and only then takes the reference on the trigger it shares its histogram with:
data->ref++;
savenamedtrigger(data->nameddata->name, data);
ret = eventhisttriggerinit(data->nameddata); if (ret < 0) { kfree(data->cmdops); data->cmdops = &triggerhistcmd; }
return ret;
eventhisttriggerinit() fails when allochistpad() cannot allocate, and nothing takes the trigger back off the list on the way out. eventhisttriggerparse() frees it, and the next lookup by name reads the freed object:
BUG: KASAN: slab-use-after-free in findnamedtrigger+0xac/0xc0 Read of size 8 at addr ffff888009346860 by task init/1 findnamedtrigger+0xac/0xc0 histregistertrigger+0xc1/0xa00 eventhisttriggerparse+0x3146/0x6af0 eventtriggerwrite+0xce/0x160 Freed by task 67: kfree+0x154/0x420 triggerkthreadfn+0xfd/0x160
Do the reference first and publish once it has succeeded, so that nothing which can fail runs after the trigger becomes findable.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In the named histogram trigger initialization path, take the trigger reference before publishing it to the global named_triggers list, and publish it only after event_hist_trigger_init() succeeds.
Event History
Frequently Asked Questions
Under what conditions can the use-after-free occur?
It requires creation of a named histogram trigger followed by failure in event_hist_trigger_init(), specifically when alloc_hist_pad() cannot allocate. The failed trigger remains on the global named_triggers list even though later cleanup frees it.
How is the freed object subsequently reached?
A later lookup of the named trigger can find the stale list entry and read the freed trigger object. The reported path reaches it through find_named_trigger during histogram-trigger registration.
What change resolves the issue?
The fix takes the shared trigger reference before publishing the named trigger to the global list. This ensures no operation that can fail runs after the trigger becomes discoverable by name.