CVE-2026-46106

eventfs: Hold eventfs_mutex and SRCU when remount walks events

published May 28, 2026

CVSS
—
EPSS
0%
Percentile
5.0
In the wild
Unconfirmed
What it is

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

eventfs: Hold eventfs_mutex and SRCU when remount walks events

Commit 340f0c7067a9 ("eventfs: Update all the eventfs_inodes from the

events descriptor") had eventfs_set_attrs() recurse through ei->children

on remount. The walk only holds the rcu_read_lock() taken by

tracefs_apply_options() over tracefs_inodes, which is wrong:

- list_for_each_entry over ei->children races with the list_del_rcu()

in eventfs_remove_rec() -- LIST_POISON1 deref, same shape as

d2603279c7d6.

- eventfs_inodes are freed via call_srcu(&eventfs_srcu, ...).

rcu_read_lock() does not extend an SRCU grace period, so ti->private

can be reclaimed under the walk.

- The writes to ei->attr race with eventfs_set_attr(), which holds

eventfs_mutex.

Reproducer:

while :; do mount -o remount,uid=$((RANDOM%1000)) /sys/kernel/tracing; done &

while :; do

echo "p:kp submit_bio" > /sys/kernel/tracing/kprobe_events

echo > /sys/kernel/tracing/kprobe_events

done

Wrap the events portion of tracefs_apply_options() in

eventfs_remount_lock()/_unlock() that take eventfs_mutex and

srcu_read_lock(&eventfs_srcu). eventfs_set_attrs() doesn't sleep so the

nested rcu_read_lock() is fine; lockdep_assert_held() pins the contract.

Comment in tracefs_drop_inode() said "RCU cycle" -- it is SRCU.

The record
Technical detail
CVSS
Not scored
CVSS v4.0
Not supplied
EPSS
0.00162 · 5.0th percentile
Published
2026-05-28T09:35Z
EPSS history
Timeline
  • 28 MAY 09:35Z
    eventfs: Hold eventfs_mutex and SRCU when remount walks events
    cvelistv5