CVE-2026-46106

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() doesnt 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.

Affected Software

References

• https://git.kernel.org/stable/c/07004a8c4b572171934390148ee48c4175c77eed
• https://git.kernel.org/stable/c/44e64d8a432837308f4dda3ffe819f1ec092a0ba
• https://git.kernel.org/stable/c/52b109f1b875b912d4ab2c5fdd8c322d47119d9b
• https://git.kernel.org/stable/c/ae9cd0b46b1890040006a2fc5e905c5d6053fd02
• https://git.kernel.org/stable/c/ed2ad73bcb0a7a6cc934097d4853b6d5124c317e