CVE-2026-46106

What it actually does

This is a local Linux kernel race condition in tracefs/eventfs handling during remount operations. When tracefs options are reapplied, the kernel walks eventfs inode child lists and updates attributes without holding the correct eventfs mutex and SRCU read-side protection. A concurrent eventfs removal, such as creating and deleting tracing probe events, can cause the walk to dereference a deleted or already freed eventfs inode, or race on eventfs attribute updates. The practical impact is kernel memory corruption leading primarily to a kernel crash, panic, or system hang, resulting in local denial of service. The CVSS vector indicates local access with low attack complexity and low privileges, with high availability impact and no direct confidentiality or integrity impact.

Why it matters to the business

An authenticated local user or process with sufficient access to tracing interfaces could crash an affected Linux system, interrupting workloads, services, containers, or infrastructure running on that host. For production servers, appliances, build systems, or shared compute environments, exploitation could cause unplanned downtime and require manual recovery or reboot. Because the vulnerability affects the Linux kernel itself, impact can extend beyond a single application to the whole host. The EPSS score is currently very low and there is no known CISA KEV listing or known ransomware association, so broad exploitation is not indicated, but systems exposing kernel tracing facilities to untrusted local users should treat this as more urgent.

How an attack unfolds

An attacker first obtains local execution on an affected Linux host with enough privilege to interact with tracefs, typically mounted at /sys/kernel/tracing or /sys/kernel/debug/tracing. The attacker repeatedly remounts the tracefs filesystem with changing mount options while simultaneously creating and removing kprobe events through the tracing interface. This forces one kernel path to walk eventfs inode children while another path removes eventfs entries and schedules their cleanup. Because the vulnerable code uses ordinary RCU protection where SRCU protection and the eventfs mutex are required, the walker can observe deleted list entries or freed eventfs inode memory. The result is a kernel fault, panic, or hang, taking the host or affected workload offline. No public exploit maturity is reported in the supplied data, and exploitation is local rather than remotely triggerable under the CVSS assessment.

How to fix it

Apply a vendor kernel update that includes the upstream fix for the eventfs remount locking issue. The fix changes tracefs option application so the events portion is protected with eventfs_mutex and eventfs SRCU read-side locking during remount walks. No exact fixed package versions were provided, so use distribution-specific advisories for Red Hat, Ubuntu, Debian, SUSE, Amazon Linux, Oracle Linux, Android, appliance vendors, and other kernel providers to identify the corrected kernel build. After installing the updated kernel, reboot into the fixed kernel and remove or retire older vulnerable kernels where operationally possible. As interim mitigation, restrict access to kernel tracing facilities to trusted administrators only, avoid granting untrusted users access to tracefs/debugfs, ensure /sys/kernel/tracing and /sys/kernel/debug/tracing are not writable by untrusted accounts or containers, and consider disabling or limiting debugfs/tracefs availability on systems where tracing is not operationally required.

How to confirm the fix worked

Confirm the system is running a kernel build that your OS vendor identifies as fixed for this eventfs/tracefs remount race. Validate with package metadata and the active runtime kernel, not only installed packages, because kernel fixes require rebooting into the updated kernel. Check the mounted tracing filesystems and permissions for /sys/kernel/tracing and /sys/kernel/debug/tracing to verify that only trusted administrative users can write to tracing controls. Review vendor changelogs or kernel source for the fix introducing eventfs_remount_lock()/eventfs_remount_unlock() around the events portion of tracefs_apply_options(). In test environments only, avoid running crash-oriented reproducers on production systems; instead validate by confirming patched kernel provenance and absence of vulnerable code paths. Monitor after remediation for kernel oops or panic messages involving eventfs, tracefs, list_del_rcu, LIST_POISON, or kprobe_events.

Typical attack path

1. Gain local code execution on an affected Linux system.
2. Confirm tracefs/debugfs tracing interfaces are mounted and writable, commonly under /sys/kernel/tracing or /sys/kernel/debug/tracing.
3. Start a loop that repeatedly remounts tracefs with changing options, such as changing uid or other mount attributes.
4. In parallel, repeatedly create and remove kprobe events via kprobe_events.
5. Trigger the race between tracefs remount option application and eventfs entry removal.
6. Cause a kernel oops, panic, hang, or reboot, resulting in denial of service.

How to detect it

Look for evidence of attempted exploitation in kernel logs, audit logs, shell histories, process accounting, and filesystem monitoring around tracefs/debugfs. Relevant log sources include journalctl/kern.log/messages/dmesg for kernel oops or panic events; auditd logs for mount/remount syscalls and writes to tracing control files; EDR telemetry for shell loops invoking mount with remount options; and command histories or process accounting showing repeated interaction with kprobe_events. Suspicious behavior includes high-frequency remounts of /sys/kernel/tracing or /sys/kernel/debug/tracing while repeatedly writing probe definitions and clearing kprobe_events. Kernel crash artifacts may mention eventfs, tracefs, eventfs_set_attrs, eventfs_remove_rec, tracefs_apply_options, list corruption, LIST_POISON, RCU/SRCU, or kprobe_events. Because successful exploitation is expected to crash or hang the host, absence of application logs after the event, unexpected reboot records, vmcore/kdump files, and panic traces are also important indicators. If crash dumps are available, inspect stack traces for eventfs/tracefs functions and concurrent kprobe event modification activity near the crash time.

• /sys/kernel/tracing/kprobe_events
• /sys/kernel/debug/tracing/kprobe_events
• mount -o remount,uid=
• /sys/kernel/tracing
• /sys/kernel/debug/tracing
• p:kp submit_bio
• eventfs_set_attrs
• eventfs_remove_rec
• tracefs_apply_options
• tracefs_drop_inode
• LIST_POISON1
• list_del_rcu
• eventfs_srcu
• eventfs_mutex
• kernel BUG
• kernel panic
• Oops:
• general protection fault
• unable to handle kernel paging request

What your security team should do

• Inventory Linux systems where tracefs or debugfs tracing interfaces are mounted and writable, especially shared servers, CI/CD workers, developer workstations, container hosts, and multi-user compute systems.
• Prioritize patching systems where untrusted or semi-trusted local users, containers, jobs, or agents can access /sys/kernel/tracing or /sys/kernel/debug/tracing.
• Deploy vendor-fixed kernels and reboot systems into the fixed version; verify the active kernel after reboot.
• Restrict tracing interface access to root and trusted administrators; remove unnecessary debugfs/tracefs mounts from production baselines where feasible.
• Harden container and sandbox profiles to prevent access to host tracing filesystems and block unnecessary mount/remount capabilities.
• Add monitoring for repeated tracefs remount activity combined with rapid writes to kprobe_events, as this pattern matches the known reproducer.
• Review recent kernel crash logs for eventfs/tracefs-related oopses to determine whether denial-of-service attempts may already have occurred.
• Because the vulnerability is not currently in KEV and has low EPSS, handle through normal kernel patch SLAs unless local multi-tenant exposure or tracing access makes the environment higher risk.