CVE-2026-72071: tracing/user_events: Fix use-after-free in user_event_mm_dup()

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

tracing/userevents: Fix use-after-free in usereventmmdup()

usereventmmdup() walks the parent mm's enabler list locklessly under rcureadlock() during fork() (from copyprocess()); it does not take eventmutex:

rcureadlock(); listforeachentryrcu(enabler, &oldmm->enablers, mmenablerslink) enabler->event = usereventget(orig->event);

usereventenablerdestroy() removes an enabler from that list with listdelrcu() and then, without waiting for a grace period, drops the enabler's userevent reference with usereventput() and frees the enabler with kfree(). A reader that loaded the enabler before the listdelrcu() can still be walking it, which leads to two use-after-frees:

- kfree(enabler) frees the enabler while that reader dereferences enabler->event.

- usereventput() may drop the last reference to the userevent, which is then freed (via delayeddestroyuserevent() on a work queue), while the same reader does usereventget(orig->event) on it.

Both are reachable by an unprivileged task that can open usereventsdata: one multithreaded process that registers an enabler and then concurrently unregisters it and calls fork() triggers the race. KASAN reports a slab-use-after-free in usereventmmdup() during clone(), with a "refcountt: addition on 0" warning when the userevent is freed.

The enabler use-after-free was found first; the userevent one was reported by XIAO WU, and the earlier enabler-only fix did not address it.

Defer both the usereventput() and the kfree(enabler) to a work item queued with queuercuwork(), so they run only after an RCU grace period, once all readers walking the enabler list have finished. The put must run in process context because usereventput() takes eventmutex on the last reference, so a work queue is used rather than callrcu(). The now-unlocked put lets the locked argument of usereventenablerdestroy() be removed; all callers are updated.