On Mon, Sep 07, 2026 at 12:59:33PM +0000, [email protected] wrote: > [Severity: High] > This isn't a bug introduced by this patch, but does this fix leave another > identical use-after-free and memory leak reachable from tracefs? > > If trigger registration fails in hist_register_trigger() after this .init() > function succeeds, the error propagates up without undoing it:
Yes, and that one is already fixed. tracing_set_clock() is the only step in hist_register_trigger() that can fail after cmd_ops->init(), and this: https://lore.kernel.org/linux-trace-kernel/[email protected]/ moves it above the init, so nothing which can fail runs after the trigger is published. This series is based on v7.3-rc2, without that patch. > [Severity: Medium] > This is a pre-existing issue, but does ignoring the return value of > save_named_trigger() break histogram sharing? Yes. On a kstrdup() failure the trigger keeps running with data->name NULL and off the list, so find_named_trigger() cannot see it, a later trigger of the same name builds its own map instead of sharing, and pause_named_trigger() misses it. Memory safety is not affected. trigger_data_alloc() runs INIT_LIST_HEAD(&trigger_data->named_list), so the unconditional del_named_trigger() in event_hist_trigger_named_free() deletes a self-linked entry and kfree()s a NULL name. Not addressed by this series.
