CVE-2026-90347
High · 8.4CVSS
8.4
EPSS
0.2%
Published
Sep 17, 2026
CISA due date
—
Cloudanix analysis
A flaw in how the system tracks changes to program instructions on certain processors lets a local user slip past security checks that should stop unauthorized actions.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Low
- Impact
- Privilege Gain
- Component
- OS kernel
- Class
- Authorization Bypass
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Incomplete synchronization of orig_x0 with x0 during ptrace-mediated syscall entry on arm64 allows a tracer to modify the first syscall argument after seccomp or audit evaluation has occurred, bypassing those authorization checks.
Why it matters to the business
Attackers with local access can evade security controls that restrict or log system calls, potentially gaining unauthorized access to kernel resources or sensitive operations on affected Linux systems.
How an attack unfolds
An attacker with the ability to attach as a ptrace tracer to a target process uses SECCOMP_RET_TRACE to intercept syscall entry, alters the x0 register value, and relies on the stale orig_x0 to prevent re-evaluation of seccomp filters or audit rules before the syscall proceeds.
How to fix it
Update the Linux kernel to a version containing the synchronization fix for orig_x0 on the syscall entry path; rebuild and deploy custom kernels if using out-of-tree configurations; enable seccomp and audit logging as compensating controls where updates are delayed.
How to confirm the fix worked
Confirm kernel source contains the ptrace GPR and syscall setting code that updates orig_x0 whenever x0 changes on syscall entry; test by attaching a tracer and verifying seccomp re-evaluation occurs after x0 modification; scan running kernels for the presence of the resolved commit.
Typical attack path
- Obtain local access and sufficient privileges to attach ptrace to a target process
- Configure seccomp filters or rely on existing ones on the target
- Use PTRACE to intercept syscall entry and modify x0 via SECCOMP_RET_TRACE
- Execute the syscall with the altered argument while bypassing seccomp/audit checks due to unsynced orig_x0
- Escalate privileges or access restricted resources
How to detect it
Review kernel audit logs and seccomp event records for syscalls where the reported argument differs from expected values at entry; look for processes using ptrace with SECCOMP_RET_TRACE on arm64; correlate with unexpected privilege changes or resource access.
What your security team should do
- Prioritize kernel updates on arm64 systems handling sensitive workloads
- Audit ptrace usage policies and restrict PTRACE_ATTACH where possible
- Enhance monitoring of seccomp and audit logs for anomalous syscall patterns
- Review downstream kernel packages for inclusion of the fix once released
The record
In the Linux kernel, the following vulnerability has been resolved: arm64: ptrace: Keep 'orig_x0' in-sync with x0 on syscall entry Commit e057b9477232 ("arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates") attempted to resolve a long-standing issue with syscall entry tracing, where a tracer is able to manipulate the first syscall argument without being subjected to seccomp or audit checking. Unfortunately, that fix was incomplete [1], as it failed to update 'orig_x0' between a tracer updating x0 during a seccomp ptrace exit (SECCOMP_RET_TRACE) and the seccomp filter being re-evaluated. Rather than add hooks to the core seccomp code, instead move the synchronisation code into the ptrace GPR and syscall setting code so that 'orig_x0' is kept up to date with x0 whenever we're stopped on the syscall entry path.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|