CVE-2026-74606: eventfs: Fix use-after-free in eventfs_remove_rec()
In the Linux kernel, the following vulnerability has been resolved:
eventfs: Fix use-after-free in eventfsremoverec()
eventfsremoverec() recursively removes the child at the current loop position. After the recursive call returns, listforeachentry() advances by reading list.next from the removed child.
If freeei() drops the final reference, releaseei() reuses the list/rcu union to queue an SRCU callback. The child may be freed before that read. The eventfsmutex serializes list updates, but it does not keep the removed child alive or prevent the SRCU callback from running.
Use listforeachentrysafe() to save the next sibling before recursively removing the current child.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
In eventfs_remove_rec(), replace list_for_each_entry() with list_for_each_entry_safe() so the next sibling is stored before the recursive removal; this prevents reading list.next from the removed child (fix use-after-free).
Linux kernel (eventfs) list_for_each_entry() -> list_for_each_entry_safe() = Use list_for_each_entry_safe() to save the next sibling before recursively removing children
Event History
Frequently Asked Questions
What sequence is required for the stale access to occur?
A recursive removal must delete the child currently being iterated, and dropping that child's final reference must allow release_ei() to reuse the list/rcU union for an SRCU callback. The child can then be freed before the iterator reads its next-list pointer.
Does holding eventfs_mutex prevent this issue?
No. The mutex serializes list updates, but it does not preserve the lifetime of a removed child or stop the SRCU callback from running.
What is the corrective change?
Iteration must save the next sibling before recursively removing the current child, using list_for_each_entry_safe() rather than list_for_each_entry().