CVE-2026-46106: eventfs: Hold eventfs_mutex and SRCU when remount walks events

Severity: medium (CVSS 5.5 v3.1)
Exploited in the wild: not listed in CISA KEV
EPSS: 0.1% probability of exploitation in the next 30 days
Public exploit or detection template: none known
Published: 2026-05-28 · updated 2026-06-25

Description

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.

Affected products

Linux kernel: from 6.6.35 before 6.6.140; from 6.9.6 before 6.12.88; from 6.13 before 6.18.30; from 6.19 before 7.0.7 — fixed in 6.12.88, 6.18.30, 6.6.140, 7.0.7

How to fix

Upgrade to a fixed version: Linux kernel 6.12.88, 6.18.30, 6.6.140, 7.0.7. Check the vendor advisory for mitigations.

References

Get alerted when CVE-2026-46106 or the next vulnerability affects your stack