CVE-2026-46106
Race Condition in Linux Kernel eventfs Subsystem
Publication date: 2026-05-28
Last updated on: 2026-05-28
Assigner: kernel.org
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linux | linux_kernel | * |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-UNKNOWN |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability exists in the Linux kernel's eventfs subsystem. It involves improper locking during the remount operation that walks through eventfs inodes. Specifically, the code only holds an rcu_read_lock() which is insufficient because it does not extend an SRCU grace period, leading to potential use-after-free conditions when eventfs_inodes are freed concurrently.
The issue arises because the list traversal over eventfs children races with their removal, causing dereferencing of invalid pointers (LIST_POISON1). Additionally, writes to eventfs attributes can race with attribute setting functions that hold a mutex, leading to data corruption or crashes.
The fix involves wrapping the events portion of the remount operation with proper locking using eventfs_mutex and srcu_read_lock to prevent these race conditions.
How can this vulnerability impact me? :
This vulnerability can lead to race conditions causing use-after-free errors and data corruption within the Linux kernel's eventfs subsystem. Such issues may result in system instability, crashes, or potential denial of service.
While the description does not explicitly mention privilege escalation or remote code execution, kernel crashes or instability can impact system availability and reliability.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability involves a race condition in the Linux kernel's eventfs subsystem during remount operations of tracefs. Detection would involve monitoring for unusual behavior or crashes related to /sys/kernel/tracing remounts or kprobe_events manipulation.
A reproducer for the issue involves running the following commands in parallel:
- 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
Running these commands may trigger the race condition, which could be detected by system crashes, kernel warnings, or LIST_POISON1 dereferences in kernel logs.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation involves applying the patch that wraps the events portion of tracefs_apply_options() in eventfs_remount_lock()/_unlock() which take eventfs_mutex and srcu_read_lock(&eventfs_srcu).
If patching is not immediately possible, avoid running concurrent remount operations on /sys/kernel/tracing and avoid manipulating /sys/kernel/tracing/kprobe_events in parallel.
Monitoring kernel logs for related errors and avoiding workloads that trigger the race condition can reduce risk until a fixed kernel version is deployed.