osbytes

Search

Find posts, projects, and members.

← back to blog

Seven stable kernels land CVE-2026-46333’s ptrace fix

2026-05-15by@osbytes5 min read
#linux #kernel #security #ptrace #cve #oss-security

Early today UTC, Qualys posted to oss-security that a bug it reported to the kernel security contact was fixed in mainline, linked Linus Torvalds’s patch, and pointed at public exploit repositories because coordinated quiet release was no longer realistic (Qualys mail to oss-security). A few hours later, Greg Kroah-Hartman’s stable announcements started landing: 7.0.8, 6.18.31, 6.12.89, 6.6.139, 6.1.173, 5.15.207, and 5.10.256, each carrying the same ptrace-side correction (LWN summary of the seven releases, 7.0.8 announcement). If you run a distro kernel derived from one of those lines, treat today’s batch as a reboot-level item, not a “read later” advisory.

What actually changed

The fix is commit 31e62c2 in Torvalds’s tree: “ptrace: slightly saner 'get_dumpable()' logic” (commit on GitHub). In plain terms, the kernel was reusing dumpable state in __ptrace_may_access() after a task’s memory map could already be gone. Dumpable was originally about whether a process image is eligible to core dump; ptrace borrowed it for access checks in other modes. When task->mm is NULL, the old path could answer the wrong question, and Qualys’s write-up plus the public ssh-keysign proof-of-concept line shows how that turns into reading root-owned material from an unprivileged context once you chain the right syscalls and timing (PoC repository linked from Qualys).

None of that is “ptrace is scary” vibes; it is a specific logic error with specific prerequisites and now specific tags you can install.

Precedent you can cite without drama

Qualys’s mail notes Jann Horn floated a related patch series back in 2020 (lore.kernel.org thread Horn linked). That does not make today’s disclosure less urgent; it does explain why some maintainers sound tired: the shape of the bug has been visible before today’s exploit drop, even if the last-mile fix and stable backports are what change outcomes for fleets.

Mitigations that are not “just flip Yama”

Sam James answered the same oss-security thread with blunt distribution notes: despite the commit title, the issue is not “ptrace-only,” so do not assume ptrace restriction policies fully contain it (Sam James follow-up). He suggests blocking pidfd_getfd as one narrow knob where your userspace stack tolerates it, and he posts a small backport matrix (clean apply on 6.6-ish lines, trivial conflict notes on 6.1, prerequisite commit called out for 5.10). Read that mail if you cherry-pick instead of taking Greg’s trees wholesale.

Separately, LWN’s comment thread under the stable-release article is already arguing about kernel.yama.ptrace_scope, user namespaces, and which combinations break the shipped proof-of-concept versus the underlying bug class (LWN comment thread). Treat those posts as community triage, not vendor support statements: they are useful if you need a temporary sysctl while you wait on a vendor kernel, but they disagree with each other in places. The correct answer for most shops is still install the stable point release your vendor ships, then revisit sysctl experiments once you are not running known-bad code.

What to run before the scanners do

  • Patch like an adult: move to a kernel that includes 31e62c2 on your supported branch; Greg’s mail for CVE-2026-46333 is the CVE anchor line if your change board wants a ticket title (Greg Kroah-Hartman CVE assignment mail summarized by LWN).
  • Assume public code: Qualys explicitly deferred its own long-form advisory to give distributions breathing room, but the exploit links are already in the open mail; plan for scanners and kiddie forks, not just the original PoC (Qualys mail).
  • Do not cargo-cult ptrace_scope alone: read Sam James’s warning first, then any sysctl recipe, then reboot onto a fixed kernel.

If your week already smelled like Dirty Frag reboots, this is a different CVE with a different patch set, same operational shape: another kernel Friday, another reason to automate measured rollouts instead of heroics.

Sources