CVE-2026-68283: tracing: Fix use-after-free freeing trigger private data

In the Linux kernel, the following vulnerability has been resolved:

tracing: Fix use-after-free freeing trigger private data

Commit 61d445af0a7c ("tracing: Add bulk garbage collection of freeing eventtriggerdata") moved the kfree() of eventtriggerdata to a kthread that runs tracepointsynchronizeunregister() before freeing. That removed the synchronization the trigger .free callbacks used to get implicitly and inline from triggerdatafree().

eventhisttriggerfree(), eventhisttriggernamedfree() and eventenabletriggerfree() free their satellite data (histdata, cmdops, enabledata) right after triggerdatafree() returns. With the synchronization now deferred to the kthread, a concurrent tracepoint handler can still reach that data through the listdelrcu()'d trigger, causing a use-after-free.

The histogram teardown must stay synchronous: removehistvars() and unregisterfieldvarhists() have to detach a synthetic event from the histogram before the trigger-removal write returns, otherwise a following command races in and the synthetic-event removal fails with -EBUSY, as the trigger-synthetic-eprobe.tc selftest catches. Make those callbacks wait with the correct barrier - tracepointsynchronizeunregister(), matching the free kthread - before freeing.

The enable trigger has no such synchronous requirement, and a blocking synchronize there would re-serialize the path that commit deliberately deferred. Give it an optional privatedatafree() callback that the free kthread runs after its grace period, and free enabledata from there.