CVE-2026-68283

The root cause of CVE-2026-68283 isn't a bug in the traditional sense — it's a mismatch between what an optimization assumed and what the consumers actually required. Commit 61d445af0a7c moved trigger freeing from inline with tracepoint_synchronize_unregister() into a deferred kthread for bulk garbage collection. The optimization treated all .free callbacks as homogeneous memory reclamation. They're not. Some trigger callbacks participate in coordination protocols with other tracepoint handlers. event_hist_trigger_free() doesn't just free memory — it detaches a synthetic event from a histogram, and that detachment must complete before the write returns because other handlers depend on the synchronous teardown ordering. The enable trigger's callback has no such downstream dependencies, so it can safely absorb deferred freeing via a new private_data_free() callback. The histogram case couldn't, and the race manifested as use-after-free in the selftest. The practical impact: if you're maintaining a kernel with this fix, verify which trigger types your tracing setup uses. Synthetic events with histograms are the vulnerable pattern. The fix adds private_data_free() to event_trigger_ops specifically to handle the enable case — but it doesn't formally enforce which pattern applies to new trigger types. Future trigger authors will face the same undocumented question: does my freeing callback need synchronous completion, or can it defer? The API now provides two hooks but no mechanism to require the right choice. What to check: grep your kernel config for CONFIG_HIST_TRIGGERS and trace_synthetic. If you're using synthetic event triggers, ensure you're on a patched kernel — the race window exists between list_del_rcu() and the actual kfree() in the deferred path, where concurrent handlers can observe freed trigger nodes. Monitor for crashes in trace_event_hist_trigger() or hist_field_name() that correlate with synthetic event modifications under load. The selftest that caught this (the race between synthetic event removal and histogram access) should be part of your kernel's test suite if it isn't already — if it's missing, request it from your vendor. The vulnerability is exploitable under normal tracing workload with concurrent synthetic event deletions, not just artificial test conditions.

Reviewed through automated stages and approved by a human before publication.