CVE-2026-46333: Linux Kernel Privilege Escalation Flaw

CVE-2026-46333 Overview

CVE-2026-46333 affects the Linux kernel's ptrace subsystem, specifically the get_dumpable() logic used by ptrace_may_access(). The flaw stems from how the kernel evaluates a task's dumpability when the task has no associated memory descriptor (mm). Because ptrace_may_access() consulted dumpability state independently of the memory image, a local authenticated attacker could observe kernel-thread details and influence access decisions that the traditional capability-drop model would otherwise restrict. The issue is classified under [CWE-269] Improper Privilege Management and affects multiple upstream stable branches addressed by eight related kernel commits.

Critical Impact

A local user with restricted privileges can leverage inconsistent get_dumpable() semantics in ptrace to access information from tasks lacking an mm pointer, undermining capability-based isolation and enabling privilege escalation paths.

Affected Products

• Linux kernel upstream stable branches referenced by eight commits in git.kernel.org
• Debian LTS distributions (per Debian LTS advisories msg00032 and msg00035)
• Downstream Linux distributions consuming the affected stable kernel series

Discovery Timeline

• 2026-05-15 - CVE-2026-46333 published to the National Vulnerability Database
• 2026-05-15 - Initial OpenWall OSS-Security disclosure post
• 2026-05-20 - Follow-up OpenWall OSS-Security discussion threads published
• 2026-05-21 - Last updated in NVD database

Technical Details for CVE-2026-46333

Vulnerability Analysis

The dumpable flag in the Linux kernel was designed to express whether a task's memory image is eligible to be core-dumped. The flag is meaningful only when a task has an associated mm (memory descriptor). The ptrace_may_access() function, however, consulted get_dumpable() for access decisions even when no mm existed, including for kernel threads and exiting tasks. This created an inconsistency: capability checks intended to restrict tracing of privileged threads could be bypassed because the dumpability state was not authoritatively bound to the task's memory image.

The upstream fix introduces a cached "last dumpability" value preserved across the lifetime of a task that previously held an mm. For kernel threads that never held an mm, the cached value remains zero. Callers without an mm must now hold CAP_SYS_PTRACE to override the cached state, restoring the expected capability semantics.

Root Cause

The root cause is improper privilege management [CWE-269] in ptrace_may_access(). The function relied on get_dumpable() semantics that were undefined for tasks without an mm, allowing access decisions to be made on stale or unintended state. The traditional model of dropping capabilities to reduce attack surface did not affect this code path because dumpability was evaluated independently of the calling task's effective privileges.

Attack Vector

Exploitation requires local access with low privileges. A local user with sufficient uid/gid matching can invoke ptrace operations such as PTRACE_MODE_READ_FSCREDS against threads lacking an mm pointer. Successful exploitation may expose information about kernel threads or facilitate access checks that should otherwise require CAP_SYS_PTRACE. A proof-of-concept repository referenced in external sources demonstrates abuse pathways targeting ssh-keysign workflows. See the GitHub PoC Repository and the OpenWall OSS-Security Post for additional technical context.

Detection Methods for CVE-2026-46333

Indicators of Compromise

• Unexpected ptrace syscalls issued by non-root processes targeting kernel threads or tasks without an mm
• Audit records (auditd) showing PTRACE_ATTACH or PTRACE_MODE_READ_FSCREDS operations from low-privileged uids against system daemons
• Anomalous access to /proc/[pid]/status, /proc/[pid]/stat, or /proc/[pid]/auxv for privileged tasks by unprivileged users

Detection Strategies

• Enable kernel auditing for the ptrace syscall and alert when invocations originate from non-administrative accounts
• Apply yama.ptrace_scope=2 or =3 and monitor for kernel log entries indicating denied ptrace attempts
• Correlate process lineage with ptrace activity to identify reconnaissance against ssh-keysign, sshd, or other setuid binaries

Monitoring Recommendations

• Centralize kernel and audit logs to a SIEM and build detections for unusual ptrace patterns across hosts
• Track kernel version inventory and flag systems running unpatched stable branches referenced in the upstream commits
• Monitor for execution of public proof-of-concept artifacts associated with ssh-keysign abuse

How to Mitigate CVE-2026-46333

Immediate Actions Required

• Apply the upstream Linux kernel patches referenced by the stable commits, including 01363cb3fbd0 and 93d4ba49d18e
• Update Debian systems per the Debian LTS Advisory and the follow-up advisory
• Restrict local shell access on multi-tenant systems until kernels are patched
• Audit setuid binaries such as ssh-keysign and remove the setuid bit where operationally feasible

Patch Information

The upstream fix reworks get_dumpable() to use a cached last-dumpability value when no mm is present and requires CAP_SYS_PTRACE to override. Eight stable-branch commits are published at git.kernel.org/stable, including 15b828a46f30, 2a93a4fac7b6, 31e62c2ebbfd, 4709234fd1b9, 6e5b51e74a40, and 8f907d345bae. Distribution vendors have released corresponding kernel updates.

Workarounds

• Set kernel.yama.ptrace_scope=2 to restrict ptrace to processes with CAP_SYS_PTRACE, or =3 to disable ptrace entirely until reboot
• Remove the setuid bit from ssh-keysign if host-based SSH authentication is not in use
• Enforce SELinux or AppArmor policies that deny ptrace permissions to unprivileged domains

# Configuration example
# Restrict ptrace scope via sysctl
echo 'kernel.yama.ptrace_scope = 2' | sudo tee /etc/sysctl.d/10-ptrace.conf
sudo sysctl --system

# Verify the setting is active
sysctl kernel.yama.ptrace_scope

# Optional: remove setuid bit from ssh-keysign if unused
sudo chmod u-s /usr/lib/openssh/ssh-keysign