RHSB-2026-004 File Descriptor Theft via Process Exit Race Condition - Linux Kernel (CVE-2026-46333)

Executive Summary

A vulnerability has been identified in the Linux kernel's permission enforcement during process teardown. A low-privileged local user could exploit this flaw to access sensitive root-owned files. Examples include SSH host private keys or the system's password hashes stored in /etc/shadow.

This issue has been assigned CVE-2026-46333 and has a severity impact of Important.

The flaw exists in __ptrace_may_access(), which skips a permission check after a process's memory is released. During process shutdown, the kernel releases memory before closing files. This creates a brief window in which an attacker can copy open files from a privileged process that still holds them.

Red Hat is expediting the release of fixes. Click the "Follow" button below to be notified of updates.

Affected Products

The following products are affected:

• Red Hat Enterprise Linux 10, 9, 8

Further, any Red Hat product that relies on the Red Hat Enterprise Linux kernel (including RHEL CoreOS) is also potentially impacted. This includes layered products such as Red Hat OpenShift Container Platform, Red Hat OpenStack Platform, and Red Hat Virtualization.

Please ensure that the underlying Red Hat Enterprise Linux kernel is current in these product environments.

Mitigation

Overall Guidance

Any hardening measures that limit local access help reduce the risk of exploitation. Examples include disabling SSH, ensuring SELinux is in enforcing mode, using the default Security Context Constraints (SCC), running workloads as non-root, and restricting oc debug access to trusted cluster administrators. This list is not exhaustive, and the applicability of each measure should be evaluated in the context of your operational requirements and security policies. Additionally, disabling any single access method does not eliminate all other means by which a user could gain local access.

Restricting process inspection

Exploitation relies on pidfd_getfd(2), which can be blocked by restricting ptrace_scope. However, the underlying flaw is in the order in which the kernel shuts down processes, and other exploitation paths that do not rely on ptrace may exist. Applying the kernel fix, when available, is the only comprehensive remediation.

Option 1: Admin-only scope

Setting ptrace_scope to 2 restricts ptrace attach to processes with CAP_SYS_PTRACE. This blocks many currently known exploitation paths, but other paths that do not rely on ptrace may exist. This is suitable for most production environments.

Warning: Option 1 prevents non-root users from attaching debuggers (e.g., gdb, strace -p) to their own processes. Evaluate the impact on development and monitoring workflows before applying.

echo "kernel.yama.ptrace_scope=2" > /etc/sysctl.d/ptrace-restrict.conf
sysctl --system

Option 2: Most restrictive scope

Setting ptrace_scope to 3 disables all ptrace attach operations. This blocks all currently known exploitation paths, but other paths that do not rely on ptrace may exist. This may be preferred in high-security environments.

Warning: Option 2 prevents all process attachment, including by root. Debuggers, monitoring tools, and any workflow that relies on ptrace will no longer function. Extensive testing will be required before deploying. Additionally, a reboot is required to remove this mitigation as it is a requirement when changing ptrace_scope from 3 to any other value.

echo "kernel.yama.ptrace_scope=3" > /etc/sysctl.d/ptrace-restrict.conf
sysctl --system

Mitigation removal

To revert either option, delete /etc/sysctl.d/ptrace-restrict.conf and run sysctl --system.