# FreeBSD fixes a ptrace(PT_SC_REMOTE) flaw that gave local root (CVE-2026-45253)

- **Published on:** 2026-05-20
- **Category:** Security
- **Original page:** https://linuxgratis.com/en/articles/cve-2026-45253-freebsd-ptrace-pt-sc-remote-privesc-local

Poor parameter validation in ptrace(PT_SC_REMOTE) let an unprivileged local user run code in the FreeBSD kernel. There is no workaround: you have to patch.

---

On 20 May 2026 the FreeBSD security team published advisory FreeBSD-SA-26:21.ptrace, fixing CVE-2026-45253, a bug in the kernel's `ptrace(PT_SC_REMOTE)` operation. It lets an unprivileged local user escalate all the way to full system control.

## What actually breaks

`ptrace` is the system call debuggers use to inspect and manipulate other processes. The `PT_SC_REMOTE` operation lets you invoke a syscall inside the process you are debugging. The bug is in how it validates parameters when that remote syscall is one of the `syscall(2)` or `__syscall(2)` meta-calls, which take the real syscall number as their first argument.

Validation of those parameters was inadequate. The advisory puts it plainly: a user with the ability to debug a process could trigger arbitrary code execution in the kernel, even if the target process had no special privileges. Debugging your own process needs no permissions. Any local account can spawn a child and attach to it. That is the uncomfortable part. There is no rare precondition and no setuid binary required; a shell is enough.

## Who is affected

Every supported version at the time of the advisory:

- FreeBSD 15.0 and 15.0-STABLE
- FreeBSD 14.4 and 14.4-STABLE
- FreeBSD 14.3

If you run FreeBSD servers where several users have shell access (hosting, shared dev boxes, jails with untrusted users), this is the scenario worth closing first. On a single-user machine the direct risk is lower, but it stays a useful step for any malware or exploit that already has local execution and wants to climb to root.

## Severity

The advisory describes kernel-level code execution starting from an unprivileged user, which in practice means a full escalation. FreeBSD did not publish a CVSS score in the advisory itself. This is the kind of flaw that is not remotely exploitable on its own, but chains cleanly with any prior local access.

## How to protect yourself

There is no workaround. Upgrading is the only option. The fixes were all committed on 20 May 2026:

- stable/15 and releng/15.0
- stable/14 and releng/14.4
- releng/14.3

You have three routes depending on how you maintain the system. With official binaries, update the kernel via `freebsd-update` on the releng branches. If you build from source, apply the patches published at security.FreeBSD.org, rebuild the kernel and reboot. Either way you need a reboot to load the patched kernel: a kernel syscall cannot be fixed live.

Check your version with `freebsd-version -k` and compare it against the patched builds before calling it done. This advisory shipped alongside several others in the same May batch (setcred, bsdinstall, libcap_net), so it is worth reviewing the full advisories page and applying them together.

See the [FreeBSD](/en/freebsd) page for supported versions and end-of-support dates.

## Source

- Official advisory: [FreeBSD-SA-26:21.ptrace](https://www.freebsd.org/security/advisories/FreeBSD-SA-26:21.ptrace.asc)
- [CVE-2026-45253 on NVD](https://nvd.nist.gov/vuln/detail/CVE-2026-45253)