CVE-2026-46106

Technical summary

CVE-2026-46106 is a synchronization bug in eventfs_set_attrs() introduced by commit 340f0c7067a9. When tracefs_apply_options() processes remount operations, it walks the ei->children list under only rcu_read_lock(), which provides insufficient protection against three concurrent modification scenarios: (1) list_for_each_entry races with list_del_rcu() in eventfs_remove_rec(), creating potential LIST_POISON1 dereferences; (2) eventfs_inode structures freed via call_srcu() can be reclaimed during the walk since rcu_read_lock() does not extend SRCU grace periods; (3) attribute writes during the walk race with eventfs_set_attr() which correctly holds eventfs_mutex. The fix wraps the events portion of tracefs_apply_options() in eventfs_remount_lock()/_unlock(), acquiring both eventfs_mutex and srcu_read_lock(&eventfs_srcu) to serialize all accesses.

Business impact

This vulnerability has limited business scope due to its local-only nature. It primarily affects environments where system administrators or privileged users frequently remount the tracefs filesystem (common in performance analysis and kernel debugging workflows) while tracing activity is ongoing. The immediate risk is denial of service through kernel panics or hangs, which could interrupt performance monitoring, continuous integration pipelines running kernel tests, or live kernel debugging sessions. There is no data breach or privilege escalation risk. Organizations running production monitoring or in-kernel profiling tools should prioritize this fix to avoid unexpected service interruptions.

Affected systems

This vulnerability affects the Linux kernel across all architectures. It only manifests when both conditions are met: (1) the tracefs filesystem is mounted (standard on systems running Linux 3.10+), and (2) a local user with CAP_SYS_ADMIN or equivalent remount privileges actively remounts the filesystem while concurrent tracing operations modify event structures. Desktop systems, servers running performance monitoring, and embedded Linux systems with kernel tracing enabled are in scope. The vulnerable code path has been present since commit 340f0c7067a9 and affects kernels where that commit is integrated.

Exploitability

Exploitability is constrained to local authenticated users with filesystem remount privileges, significantly limiting practical impact. The race condition requires precise timing—the attacker must trigger remount operations (via mount -o remount) while concurrently creating or deleting kprobe/tracepoint events through /sys/kernel/tracing/kprobe_events. The provided reproducer demonstrates repeatability but success depends on scheduling races, making it unreliable for direct exploitation. An unprivileged user cannot trigger this bug. The vulnerability is more likely discovered and triggered inadvertently during concurrent administrative operations than through deliberate attacks.

Remediation

The Linux kernel maintainers resolved this vulnerability by implementing proper locking in the remount code path. Users must apply the kernel patch that introduces eventfs_remount_lock() and eventfs_remount_unlock() functions, which acquire eventfs_mutex and srcu_read_lock(&eventfs_srcu) during the event walk in tracefs_apply_options(). This ensures mutual exclusion with eventfs_set_attr() and prevents use-after-free of SRCU-freed structures. Verify the patch is included in your kernel release via git log or the vendor advisory.

Patch guidance

Obtain and apply the kernel patch addressing eventfs synchronization. On Debian/Ubuntu systems, ensure you are running a fixed stable kernel version published after the vulnerability disclosure (consult your distribution's security advisory for specific version numbers). On RHEL/CentOS, check for kernel updates in your subscription channels. For systems running custom or upstream kernels, apply the commit that adds eventfs_remount_lock() protection. After patching, rebuild the kernel or apply your distribution's binary updates and reboot. Verify the fix by checking the kernel version and confirming the presence of the synchronization code in /boot/config (if available) or via kernel source inspection.

Detection guidance

Detection of exploitation attempts is challenging because the race condition manifests as crashes or hangs rather than logged attack patterns. Monitor system logs for kernel panic messages mentioning LIST_POISON or use-after-free errors in the tracefs/eventfs code. Enable kernel debugging (CONFIG_DEBUG_LIST, CONFIG_DEBUG_OBJECTS) in development environments to catch list corruption early. Track repeated mount/remount operations on /sys/kernel/tracing combined with heavy kprobe_events activity—unusual concurrency in audit logs may indicate intentional triggering. Most importantly, prioritize patching over detection, as the bug is reliably triggered only by deliberate race exploitation and is far more likely discovered through normal concurrent administration.

Why prioritize this

While this is a MEDIUM severity local vulnerability, it warrants prompt patching in specific high-risk scenarios. Prioritize if your infrastructure relies on real-time kernel performance monitoring, continuous integration systems running kernel tests, or development teams actively using kprobes and dynamic tracing. For general-purpose servers without active tracing workloads, this is a lower-urgency patch. The lack of remote exploitability and the requirement for local privileges mean this does not demand emergency response, but it should be included in the next standard kernel update cycle to eliminate denial-of-service risk in monitoring-heavy environments.

Risk score, explained

The CVSS 3.1 score of 5.5 (MEDIUM, vector AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) reflects a local attack vector (AV:L), low attack complexity (AC:L), and requirement for low privileges (PR:L). The high impact on availability (A:H) reflects the crash/hang potential. Confidentiality and integrity impact are rated none (C:N/I:N) because the vulnerability does not leak data or enable unauthorized writes to user-controlled memory. The single-user scope (S:U) limits blast radius. The score appropriately downgrades from HIGH to MEDIUM due to local-only exploitability; however, in environments with shared kernel tracing infrastructure or untrusted local users, the practical impact may feel higher.

Frequently asked questions