CVE-2026-64371

What it actually does

This is a local Linux kernel race condition in procfs permission checks. Several /proc code paths call ptrace_may_access() without holding exec_update_lock, allowing the checked task to change execution state during the access-control decision. Because ptrace_may_access() is used to decide whether one process may inspect another process, the race can lead to inconsistent authorization for procfs entries such as process status, wait channel, namespace links, and map_files. The most likely technical impact is unauthorized local process introspection or information disclosure across process/user boundaries; exploitation requires local code execution and precise timing.

Why it matters to the business

Successful exploitation could let a local attacker obtain information about other processes that should be restricted, such as process metadata, namespace relationships, execution state, or memory-mapped file references. In multi-user Linux systems, shared hosting, developer workstations, CI runners, container hosts, and bastion systems, this can weaken tenant or user isolation and support follow-on attacks. The current public exploitation signal is low: EPSS is 0.00177, it is not listed in CISA KEV, is not known to be used in ransomware campaigns, and no public exploit maturity is reported; however, kernel issues should still be remediated during normal patch cycles because they affect a core isolation boundary.

How an attack unfolds

An attacker first needs the ability to run local code on a vulnerable Linux system. They then create or target a process whose credentials, memory descriptor, or execution state is changing, typically by repeatedly causing execve transitions while another thread or helper process repeatedly accesses sensitive procfs paths. The attacker races procfs reads or lookups that rely on ptrace_may_access() but were not protected by exec_update_lock. If the timing is successful, the kernel may make the access decision using inconsistent task state and allow data to be returned that would normally be denied. The attacker can use the exposed information for reconnaissance, container or namespace mapping, process discovery, or to support subsequent local privilege-escalation or credential-targeting activity. There are no named threat actors or active campaigns reported for this issue in the provided data.

How to fix it

Apply the Linux kernel update from the operating system or distribution vendor that includes the procfs ptrace_may_access() locking fix for this vulnerability. No exact affected product list or fixed package versions were provided, so use vendor advisories and kernel package changelogs to identify the corrected build for each distribution. Prioritize shared Linux systems, container hosts, CI/CD runners, virtualization hosts, bastion hosts, and any environment where untrusted or semi-trusted users can run local code. If immediate patching is not possible, reduce exposure by limiting local shell access, isolating untrusted workloads, tightening container boundaries, enabling procfs restrictions where compatible such as hidepid for /proc mounts, enabling Yama ptrace_scope where appropriate, and using least-privilege service accounts. Mitigations reduce attack surface but should not be treated as a complete substitute for the kernel fix.

How to confirm the fix worked

Confirm that the running kernel package has been updated to a vendor release that references the procfs ptrace_may_access(), exec_update_lock, mm_access(), do_task_stat(), proc_pid_wchan(), proc_map_files_lookup(), proc_map_files_readdir(), proc_ns_get_link(), or proc_ns_readlink fix. Verify the active kernel after reboot with standard system tools such as uname -r and the package manager’s installed kernel version, and ensure the machine is actually booted into the patched kernel rather than only having it installed. Review vendor security advisories for the specific distribution to confirm this CVE is marked fixed. Where feasible, validate that unprivileged users cannot access restricted /proc data for processes owned by other users and that expected procfs hardening settings, such as hidepid and ptrace_scope, remain enabled after the update.

Typical attack path

1. Gain local code execution as an unprivileged user or compromised service account on a vulnerable Linux host.
2. Identify higher-value local processes, containers, namespaces, or users whose procfs data should not be accessible.
3. Run a tight loop that triggers exec transitions in the target or cooperating process while concurrently accessing affected procfs entries.
4. Repeatedly read or enumerate paths such as process stat, wchan, namespace symlinks, or map_files entries to win the race.
5. Collect any procfs data returned despite normal ptrace-based access restrictions.
6. Use the information for process reconnaissance, namespace/container mapping, or preparation for additional local attacks.

How to detect it

Post-exploitation detection is difficult because a successful race may only appear as ordinary local procfs access and does not create a unique kernel log message by default. Focus on behavioral evidence from auditd, EDR, eBPF telemetry, shell history, and process accounting. Look for unprivileged users or service accounts repeatedly accessing /proc entries for processes they do not own, especially /proc/<pid>/stat, /proc/<pid>/wchan, /proc/<pid>/ns/*, and /proc/<pid>/map_files, combined with very high rates of execve, openat, getdents64, readlink, or readlinkat syscalls. Investigate locally compiled or dropped binaries that perform tight loops against procfs, processes consuming high CPU while reading /proc, and activity on shared hosts where one user account enumerates another user’s processes. If audit rules are available, search for syscall records involving open/openat, readlink/readlinkat, and getdents64 on sensitive /proc paths, correlated with UID mismatches between the accessor and target process owner. Absence of these events does not prove non-exploitation unless detailed syscall or EDR telemetry was enabled at the time.

• /proc/*/stat
• /proc/*/wchan
• /proc/*/ns/
• /proc/*/map_files
• exec_update_lock
• ptrace_may_access
• proc_pid_wchan
• proc_map_files_lookup
• proc_map_files_readdir
• proc_ns_get_link
• proc_ns_readlink
• do_task_stat

What your security team should do

• Inventory Linux systems where untrusted users, build jobs, containers, or third-party workloads can execute local code, and prioritize those systems for kernel updates.
• Patch to the vendor-provided fixed kernel and reboot into the updated kernel; kernel package installation alone is insufficient if the old kernel is still running.
• For container hosts and shared systems, review /proc mount options, Yama ptrace settings, user namespace policy, and workload isolation controls as defense-in-depth.
• Monitor for unusual high-frequency access to sensitive /proc paths by unprivileged users, especially when paired with rapid execve activity.
• Because EPSS is low and there is no KEV listing or known exploit maturity, handle this through normal vulnerability-management SLAs unless local multi-user exposure or untrusted workload execution increases risk.
• Retain audit or EDR telemetry for local process execution and procfs access on high-risk Linux hosts to support retrospective investigation if exploit code becomes public.