Re: [PATCH] perf synthetic-events: Check schedstat domain allocation failure

[Hui Su <sh_def@163.com>]

On Sat, Sep 12, 2026 at 03:21:14AM +0000, sashiko-bot@kernel.org wrote:
> [Severity: High]
> This isn't a bug introduced by this patch, but there is a pre-existing issue
> in the caller perf_event__synthesize_schedstat().
> 
> If the loop in perf_event__synthesize_schedstat() encounters a line starting
> with a character other than 'c' or 'd' (such as an unhandled trailing
> newline or a new record type from a newer kernel):
[...]
> Does this check incorrectly assume the event pointer is NULL if an unrecognized
> line is parsed?
> 
> Because the event pointer is freed at the end of the previous iteration but not
> reset to NULL, it retains a dangling pointer. The check if (!event) will pass,
> leading the code to actively pass the stale pointer to the process() callback:
[...]
> Could this trigger a use-after-free and a subsequent double-free?
> 
> Would it be safer to initialize the event pointer to NULL at the start of
> each loop iteration?

Good catch. I confirmed that this is a valid pre-existing bug.

After a successful iteration, `event` is freed but not reset to NULL. If a
subsequent iteration starts with an unrecognized schedstat record type, no new
event is assigned. The stale pointer therefore passes the `if (!event)` check,
may be passed to `process()`, and may then be freed again on that iteration.

While checking the event lifetime in this loop, I also noticed another
pre-existing issue: when `user_requested_cpus` filters out the synthesized
event, the `continue` path skips `free(event)`, leaking the event.

These issues were introduced in the same schedstat synthesis code, but they
are independent of the missing allocation check fixed by this patch. I will
keep this patch focused on the allocation failure and send a separate patch
fixing the event lifetime in `perf_event__synthesize_schedstat()`.

Thanks for catching this.

Hui