PT-2026-44229 · Linux · Linux
Published
2026-05-28
·
Updated
2026-05-28
·
CVE-2026-46106
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux