CVE-2026-64375

What it actually does

This is a local Linux kernel race condition in procfs access control for process file-descriptor links. The vulnerable path performs a ptrace-style permission check against a task looked up by PID, then later performs the actual procfs link operation after looking up the PID again. Because the checked task and the accessed task may differ during process exit, exec, or PID reuse windows, a local low-privileged user may be able to bypass intended /proc/<pid>/fd access restrictions. Successful exploitation can expose sensitive file descriptors or process-linked resources belonging to another process and may enable further confidentiality, integrity, or availability impact depending on what descriptors or kernel-mediated objects are reached.

Why it matters to the business

Systems running affected Linux kernel versions may allow a local user or already-compromised low-privileged process to cross process isolation boundaries and access sensitive process resources. In practical terms, this could assist credential theft, data exposure, lateral movement from an application compromise, container or service isolation weakening, or privilege-escalation chains. The CVSS score is high, but EPSS is currently very low, it is not listed in CISA KEV, and no public exploit maturity is reported, so urgency should be driven primarily by exposure of multi-user systems, shared compute, container hosts, and systems where untrusted local code can run.

How an attack unfolds

An attacker first needs local code execution as a non-privileged user. They then repeatedly interact with procfs file-descriptor links such as /proc/<pid>/fd/<n> while racing process lifecycle events, exec transitions, or PID reuse. The vulnerable sequence checks ptrace access against one task reference, but the eventual procfs link resolution can occur against a different task obtained through a second PID lookup. If the attacker wins the race, access intended to be denied may be granted against a target process. The attacker can then inspect or interact with exposed descriptors or linked resources, potentially reading sensitive files, discovering secrets, interfering with privileged process resources, or using the access as one step in a broader local privilege-escalation chain.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the procfs FD-link race by ensuring proc_pid_get_link() and proc_pid_readlink() use the corrected task locking and access-check behavior around exec_update_lock. Because no product-specific fixed versions were provided, obtain patched kernels from the relevant Linux distribution, appliance vendor, cloud image provider, or kernel source branch. Prioritize kernel updates on multi-user hosts, container platforms, CI/CD runners, bastion systems, developer workstations, shared HPC systems, and any server that permits untrusted local code execution. If immediate patching is not possible, reduce risk by limiting local shell access, restricting untrusted workloads, hardening container boundaries, enabling least privilege for service accounts, reducing process visibility where supported, and monitoring abnormal procfs enumeration. Reboot or live-patch as required by the vendor so the running kernel, not only the installed package, is fixed.

How to confirm the fix worked

Confirm remediation by checking the running kernel version and matching it to a vendor advisory or kernel build that contains the procfs access-control race fix. Validate that the host has actually booted into the patched kernel using commands such as uname -a and distribution package tooling, rather than only confirming that an updated kernel package is installed. Review vendor changelogs for wording related to proc_pid_get_link(), proc_pid_readlink(), ptrace_may_access(), exec_update_lock, proc_fd_access_allowed(), or call_proc_get_link(). Where practical, run a controlled regression test or security test that attempts repeated readlink/open operations against /proc/<pid>/fd entries across process exec/exit transitions and verifies access remains denied when ptrace permissions should not allow it. For fleets, inventory kernel versions and flag systems with older or custom kernels that may not include the fix.

Typical attack path

1. Obtain local execution on a Linux host as a low-privileged user, compromised service account, container process, or untrusted shell user.
2. Identify high-value local processes whose procfs file-descriptor links may expose secrets, files, sockets, namespaces, or other sensitive resources.
3. Rapidly issue readlink/open-style operations against /proc/<pid>/fd/<n> while inducing or waiting for process exec, exit, restart, or PID reuse activity.
4. Win the race between the ptrace access check and the later procfs link operation so the checked task differs from the accessed task.
5. Use any exposed file descriptor or linked resource to read sensitive data, interact with privileged resources, or support further local escalation.
6. Clean up transient tooling and rely on the fact that failed procfs race attempts may leave little application-level evidence.

How to detect it

Exploitation is a local race condition and may not produce a deterministic kernel log entry or crash. Detection should focus on behavioral evidence from auditd, eBPF-based telemetry, EDR for Linux, syscall tracing, shell history, process accounting, and authentication/session logs. Look for non-administrative users or unexpected service accounts repeatedly invoking readlink, open, stat, access, or similar syscalls against /proc/<pid>/fd/<n> paths, especially at high frequency or against privileged processes. Correlate procfs FD enumeration with process restart storms, rapid fork/exec activity, PID cycling, failed permission checks, suspicious local exploit tooling, compiler usage, downloaded binaries, or subsequent access to sensitive files and sockets. Useful log sources include Linux audit logs, syslog/journald, EDR process/file events, command history where available, container runtime logs, Kubernetes node telemetry, and process accounting records. Because no known public exploit or threat actor campaign is reported, absence of known signatures does not rule out exploitation; prioritize anomaly-based detection and forensic review of vulnerable high-risk hosts.

• /proc/*/fd/*
• /proc/[0-9]*/fd/[0-9]*
• readlink /proc/
• readlinkat /proc/
• open /proc/
• openat /proc/
• stat /proc/
• lstat /proc/
• ptrace_may_access
• proc_pid_get_link
• proc_pid_readlink
• exec_update_lock
• call_proc_get_link

What your security team should do

• Prioritize patching shared Linux systems and hosts that run untrusted or semi-trusted local workloads, including container hosts, CI runners, developer jump boxes, and multi-user servers.
• Create an inventory of running kernel versions and compare them against distribution or vendor advisories that include the procfs FD-link race fix.
• Ensure kernel updates are completed with the required reboot or live-patch activation and verify the running kernel after maintenance.
• Until patched, restrict local interactive access and reduce the ability of low-privileged users or containers to enumerate host procfs resources.
• Monitor for unusual high-volume readlink, open, or stat activity against /proc/<pid>/fd paths, especially from non-administrative users or unexpected service accounts.
• Review sensitive services for unnecessary long-lived file descriptors to secrets, private keys, credentials, database sockets, or privileged resources.
• Treat evidence of suspicious procfs FD enumeration on vulnerable systems as possible post-compromise activity and investigate the originating user, process tree, and adjacent privilege-escalation attempts.