From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-cve-announce@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@kernel.org>
Subject: CVE-2026-68171: arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates
Date: Mon, 10 Aug 2026 13:58:08 +0200 [thread overview]
Message-ID: <2026081005-CVE-2026-68171-db78@gregkh> (raw)
From: Greg Kroah-Hartman <gregkh@kernel.org>
Description
===========
In the Linux kernel, the following vulnerability has been resolved:
arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates
When seccomp support was originally added to arm64 in a1ae65b21941
("arm64: add seccomp support"), seccomp was erroneously called _before_
the ptrace syscall-enter-stop and therefore the tracer could trivially
manipulate the syscall register state after the seccomp check had
passed. This was subsequently fixed in a5cd110cb836 ("arm64/ptrace: run
seccomp after ptrace") by moving the seccomp check after the tracer has
run. Unfortunately, a decade later, that fix has been reported to be
incomplete.
On arm64, both the first argument to a syscall and its eventual return
value are allocated to register x0. In order to facilitate syscall
restarting and querying of syscall arguments on the syscall exit path,
the original value of x0 is stashed in 'struct pt_regs::orig_x0' early
during the syscall entry path and is returned for the first argument by
syscall_get_arguments(). Unlike 32-bit Arm, this stashed value is not
directly exposed via ptrace() and so changes to register x0 made by the
tracer on a syscall-enter-stop are not reflected in 'orig_x0'. This
means that seccomp, syscall tracepoints and audit can observe a stale
value for the register compared to the argument that will be observed by
the actual syscall.
Re-sync 'orig_x0' from x0 on the syscall entry path following a
potential ptrace stop (i.e. PTRACE_EVENTMSG_SYSCALL_ENTRY or
SECCOMP_RET_TRACE). This behaviour is limited to native tasks (because
compat tasks expose 'orig_r0' to ptrace) where the syscall is not being
skipped (because x0 is updated to hold the return value of -ENOSYS in
that case).
The Linux kernel CVE team has assigned CVE-2026-68171 to this issue.
Affected and fixed versions
===========================
Issue introduced in 4.8 with commit a5cd110cb8369d6b37ef5ccfe56b3fa1338c9615 and fixed in 6.6.148 with commit 8000a5f4d1d192f5bb3e4f29e7606a9460d376df
Issue introduced in 4.8 with commit a5cd110cb8369d6b37ef5ccfe56b3fa1338c9615 and fixed in 6.12.101 with commit b7afd2a80593dde3f4a68c9a9f73752f9c340e85
Issue introduced in 4.8 with commit a5cd110cb8369d6b37ef5ccfe56b3fa1338c9615 and fixed in 6.18.42 with commit 64ab0964c7db949abbd3c56268a220e2b77f7b9e
Issue introduced in 4.8 with commit a5cd110cb8369d6b37ef5ccfe56b3fa1338c9615 and fixed in 7.1.6 with commit e59c2476ef755221da31f4e26f6b89712ecf50f1
Issue introduced in 4.8 with commit a5cd110cb8369d6b37ef5ccfe56b3fa1338c9615 and fixed in 7.2-rc5 with commit e057b94772328221405b067c3a85fe479b915dc8
Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.
Unaffected versions might change over time as fixes are backported to
older supported kernel versions. The official CVE entry at
https://cve.org/CVERecord/?id=CVE-2026-68171
will be updated if fixes are backported, please check that for the most
up to date information about this issue.
Affected files
==============
The file(s) affected by this issue are:
arch/arm64/kernel/ptrace.c
Mitigation
==========
The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes. Individual
changes are never tested alone, but rather are part of a larger kernel
release. Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all. If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
https://git.kernel.org/stable/c/8000a5f4d1d192f5bb3e4f29e7606a9460d376df
https://git.kernel.org/stable/c/b7afd2a80593dde3f4a68c9a9f73752f9c340e85
https://git.kernel.org/stable/c/64ab0964c7db949abbd3c56268a220e2b77f7b9e
https://git.kernel.org/stable/c/e59c2476ef755221da31f4e26f6b89712ecf50f1
https://git.kernel.org/stable/c/e057b94772328221405b067c3a85fe479b915dc8
reply other threads:[~2026-08-10 12:04 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2026081005-CVE-2026-68171-db78@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=cve@kernel.org \
--cc=gregkh@kernel.org \
--cc=linux-cve-announce@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.