[CVE-2026-89603][IMPORTANT] entry: Fix seccomp bypass after ptrace with TSYNC

[AL-KERNEL <alkernel@kernelcve.org>]

CVE: CVE-2026-89603
Priority: IMPORTANT
AL-KERNEL base severity: IMPORTANT
KPANIC flag: YES
Patch: entry: Fix seccomp bypass after ptrace with TSYNC
Commit: 459f33f82864723a7fa366cf1091d9c6c893b6b2
Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=459f33f82864723a7fa366cf1091d9c6c893b6b2
Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-89603
Analysis date: Fri, 11 Sep 2026 20:37:39 -0400
ActionableScore: 6
ActionableScore lower bound: 5
Actionable bucket: Actionable Moderate / Strong Important candidate requiring manual review
Manual review required: YES

Summary:
No one-sentence report phrase was found.

======================================================================
ABOUT THIS REPORT
======================================================================

The original Linux kernel CVE announcement for CVE-2026-89603 is available here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-89603

The original announcement does not normally provide a security severity
estimate, CVSS assessment, or enough information to determine whether the
reported kernel bug represents a practically relevant security issue.

This report was generated by AL-KERNEL, an AI-assisted Linux kernel
vulnerability analysis system developed by Alexander Larkin. It combines
an autonomous classifier with LLM-assisted technical analysis and a
separate ActionableScore mechanism.

The purpose of this report is to prioritize Linux kernel CVEs before
manual review, identify cases that require prompt investigation, and
support automatic closure of issues that are unlikely to have meaningful
security impact.

Published priority for this report: IMPORTANT
Manual review required: YES

A detailed explanation of the methodology and priority rules is included
at the end of this message.

======================================================================
AL-KERNEL CLASSIFICATION RESULT
======================================================================

CVE-2026-89603	IMPORTANT	https://www.kernelcve.org/list/?q=CVE-2026-89603 CHECK WITH IMPACT FROM ORIG NN LOW	Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H';CWE-362;CWE-367;CWE-693;CWE-284;Other CVSS 'AV:L/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:L';BEST CVSS score: '7.8';DESCR 'A seccomp bypass can occur when a thread is stopped in syscall_trace_enter for ptrace while another thread installs a TSYNC seccomp filter. The stopped thread can receive the new SYSCALL_WORK_SECCOMP flag, but syscall_trace_enter may continue with a stale cached work value and miss the newly required seccomp check. This can allow a prohibited syscall such as execve to run even though the new filter was intended to block it, especially when ptrace has changed the syscall number during the stop. For the CVSS the PR:L is used because the attacker needs local code execution in a process or sandbox context, but does not need full administrator privileges. The issue is not network reachable and is triggered through local ptrace and seccomp control flow. Impact is a security policy bypass and at least local denial of service or sandbox restriction bypass. In the paranoid interpretation, confidentiality, integrity, and availability can be high because bypassing seccomp may allow access to operations intentionally blocked by a sandbox policy.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Actionable Moderate / Strong Important candidate requiring manual review (with actual score 6)  SKIP CVE-2026-89603 UNKNOWN SKIP No affected files built, so skip this CVE NO  - - unknown 	MAYBE	RACE HARDWARE  KPANIC INCREASED_TO_MODERATE7_FROM_LOW_BASED_ON_GUESSCVSS_AND_ACTIONABLESCOREHIGHER4 KPANIC INCREASED_TO_HIGH_BASED_ON_ACTIONABLESCOREHIGHERTHAN5	-	-	checked

======================================================================
ACTIONABLESCORE ANALYSIS
======================================================================

ActionableScore=6
ActionableScoreLower=5
PrimitiveClass=CLASS_A
RealUAF=NO
HostAdminRequired=NO
NamespaceScopedPrivilege=NO
ImportantCandidate=YES
ManualReview=REQUIRED
AutoDowngradeAllowed=NO

1. ActionableScore

* Raw conservative score: 5
* Conservative score: 5. No floor or cap changed the score.
* Raw paranoid score: 6
* Paranoid score: 6. No floor or cap changed the score.
* Final recommended bucket: **Actionable Moderate / Strong Important candidate requiring manual review**::

2. Signal breakdown

Conservative signals:

* +2 Concrete authorization / security policy bypass. The patch directly establishes that SYSCALL_WORK_SECCOMP can be set by TSYNC but then missed because syscall_trace_enter uses a stale cached work value, causing the seccomp decision to change from intended DENY to effective ALLOW.
* +1 Local unprivileged trigger. The supplied text explicitly says an unprivileged process could execute a prohibited syscall. Seccomp filters can be installed by unprivileged tasks under normal no_new_privs based sandbox semantics.
* +1 Practical exploit chain strongly implied. The described chain is ptrace stop, TSYNC seccomp installation, stale syscall_work, skipped seccomp check, and execution of a syscall such as execve that the filter intended to block.
* +1 Central security path fan-out. The affected code is generic syscall entry handling, and the bypass applies to seccomp enforcement for syscalls rather than to a single diagnostic or low-value helper.

Paranoid additional signal:

* +1 Security-boundary consequence ambiguity. Seccomp is commonly used as a sandbox boundary, and bypassing a newly installed filter can enable operations intentionally blocked by policy. The exact downstream protected resource or LPE chain is not established, so this is limited to one additional point rather than a stronger exploit consequence.

Non-awarded signals:

* RealUAF not awarded. No stale heap object, post-free use, double release, or lifetime refcount mutation is established.
* Memory corruption not awarded. The primitive is stale security state / stale flag evaluation, not kernel memory corruption.
* Controlled reclaim, arbitrary write, and kernel read/write not demonstrated.
* Privileged FD/resource theft not awarded. No supplied evidence connects the bypass to pidfd_getfd, protected file access, credential theft, or a concrete root chain.
* Extra availability not awarded. Any DoS possibility is secondary to policy bypass and no independent host-wide crash primitive is shown.
* Race penalty not applied. Although this is a race, the relevant window is a ptrace stop where another thread can perform TSYNC, which is more controllable than a narrow one-shot timing race.

3. Reachability analysis

The evaluated attacker is a local below-host-admin process or sandboxed process participating in ptrace and seccomp control flow. Host administrator privilege is not required according to the supplied description.

The raw helper-level path involves syscall_trace_enter, ptrace handling, and seccomp enforcement. The security-relevant operation is local syscall execution. There is no direct network reachability.

Namespace-scoped privilege is not the relevant model here. The issue does not depend on CAP_NET_ADMIN or namespace-local device control. It depends on local process behavior, ptrace stop state, and TSYNC seccomp filter installation.

Prior privileged setup is not established as required. Some deployments may restrict ptrace relationships or sandbox architecture, but the supplied evidence states unprivileged process reachability and does not prove a host-admin prerequisite.

The race is timing dependent, but it is not treated as a hard uncontrollable race for ActionableScore because the stopped thread remains in ptrace handling while another thread can install the TSYNC filter.

4. Primitive and severity interpretation

The exact primitive is a seccomp security policy bypass caused by stale syscall_work state after ptrace handling. The new SYSCALL_WORK_SECCOMP flag can be installed on a stopped thread, but the syscall entry path may continue using the old cached work value and skip the seccomp check.

This is not an active structured UAF and not fixed stale storage. There is no concrete repeated release or refcount operation. There is no first lifetime operation that may free an object and no second lifetime mutation through a dangling reference.

PrimitiveClass is CLASS_A because a concrete security-boundary / authorization policy bypass is established. The demonstrated consequence is execution of a syscall that a newly installed seccomp filter intended to block. The speculative consequence is broader sandbox escape impact depending on which syscalls are blocked by the policy, but no specific protected resource theft or root escalation chain is supplied.

ImportantCandidate is YES because seccomp is a meaningful kernel-enforced sandbox boundary and the bypass is directly in syscall entry enforcement. AutoDowngradeAllowed is NO because automatically closing this as ordinary Moderate would discard a concrete security-boundary bypass with unresolved downstream impact.

Likely operational severity is Actionable Moderate with Strong Important candidate review. It should not be treated as a simple crash-only or correctness-only race.

5. One-sentence report phrase

A race in syscall_trace_enter can let a thread miss a TSYNC installed seccomp flag after ptrace handling, allowing a local unprivileged process to execute a syscall that the new filter intended to block.

6. Manual review recommendation

MANUAL CHECK REQUIRED

Reason: this is a concrete seccomp security-boundary bypass in generic syscall entry handling, with local unprivileged reachability and unresolved sandbox escape impact.

7. Call-site confidence

Call-site confidence: high

======================================================================
UPSTREAM PATCH SUMMARY
======================================================================

Patch: entry: Fix seccomp bypass after ptrace with TSYNC
Commit: 459f33f82864723a7fa366cf1091d9c6c893b6b2
Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=459f33f82864723a7fa366cf1091d9c6c893b6b2

Commit description:

Sashiko review pointed out the following issue.

If a thread is stopped in syscall_trace_enter() for ptrace, another
thread can install a seccomp filter with SECCOMP_FILTER_FLAG_TSYNC
(e.g., via seccomp_attach_filter()). This will successfully set
SYSCALL_WORK_SECCOMP on the stopped thread, but syscall_trace_enter()
evaluates a cached 'work' variable sampled on entry. Consequently,
the subsequent check for SYSCALL_WORK_SECCOMP misses the newly
assigned flag, and the filter is silently bypassed.

This race condition could allow an unprivileged process to execute
a prohibited system call (e.g., execve) that the newly installed filter
was intended to block, especially since the tracer might have modified
the system call number during the ptrace stop.

Fix this by re-reading the syscall_work flags after ptrace handling,
so that any new SYSCALL_WORK_SECCOMP flag set by another thread via
TSYNC during the ptrace stop is observed before the subsequent
seccomp check.

Fixes: 142781e ("entry: Provide generic syscall entry functionality")
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/all/20260629132914.1135C1F000E9@smtp.kernel.org/
Link: https://patch.msgid.link/20260713025712.416366-1-ruanjinjie@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>

Changed files:
  kernel/entry/syscall-common.c

Diff excerpt:

Not included in this email. See the upstream URL for the full patch.

Full patch:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=459f33f82864723a7fa366cf1091d9c6c893b6b2

======================================================================
DETAILED REPORT METHODOLOGY
======================================================================

The original Linux kernel CVE announcement for CVE-2026-89603 can be found here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-89603

The original CVE announcement normally does not include a security-level
estimate. In particular, it may not contain a CVSS assessment, an impact
level, or enough information to determine whether the reported bug is a
practically relevant security issue. One purpose of this parallel CVE list
is to provide that missing technical and prioritization information.

The original goal of the AL-KERNEL project was to prioritize Linux kernel
CVE analysis automatically before manual review. The system can also help
identify non-security issues that may be suitable for automatic closure.

This report was generated by AL-KERNEL, an AI-assisted Linux kernel
vulnerability analysis system developed by Alexander Larkin.

The first analysis stage combines an autonomous classifier with additional
LLM-based analysis. The autonomous classifier runs locally on a CPU and is
based on a backpropagation neural network. Together, these mechanisms
produce a technical vulnerability description, identify likely weakness
types, estimate CVSS severity, and provide input for ActionableScore.

Two CVSS estimates are retained because incomplete kernel vulnerability
information often permits more than one defensible interpretation:

  Conservative CVSS vector: AV:L/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:L
  The Best / paranoid CVSS vector: AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H
  The Best / paranoid CVSS score: 7.8

The conservative vector represents a lower-impact interpretation.
The Best/paranoid vector intentionally represents a plausible upper-bound
interpretation and should not automatically be treated as demonstrated
real-world impact.

CVSS may also need to be adjusted for a particular Linux deployment,
because actual reachability, privileges, enabled kernel configuration,
hardware, namespaces, exposed device nodes, and other environmental
conditions can differ significantly between systems.

A separate ActionableScore mechanism evaluates practical remediation
urgency. Its analysis may include reachability, attack prerequisites,
subsystem exposure, memory-corruption characteristics, denial-of-service
reliability, and possible confidentiality, integrity, or
privilege-escalation impact.

  Conservative ActionableScore: 5
  Paranoid ActionableScore: 6

The final base severity is taken directly from the second tab-separated
field of the AL-KERNEL classification result. ActionableScore does not
replace or independently override that final AL-KERNEL decision, and
if ActionableScore adjusted impact level of ALKERNEL, then you would see
self-readable flags above like INCREASED_TO_HIGH_BASED_ON_ACTIONABLESCOREHIGHEREQTHAN7.

For an AL-KERNEL result of MODERATE, this report uses the following
additional presentation split:

  ActionableScore below 5   -> MODERATE REGULAR
  ActionableScore 5 or more -> MODERATE 7.0

The distinction between MODERATE REGULAR and MODERATE 7.0 makes it
possible to identify Moderate issues that should receive manual analysis
and fixes before lower-priority MODERATE REGULAR issues. In many cases,
MODERATE REGULAR fixes may wait for a later rebase or routine update.

There is one override in which MODERATE REGULAR becomes MODERATE 7.0
even when the ActionableScore is below 5. When the AL-KERNEL result
contains the KPANIC flag, a MODERATE result is always presented as
MODERATE 7.0. The KPANIC flag selected with few regexps without
usage of AI at all, so it helps to detect cases when Kernel Crash happens
and similar (to filter False-Negative results from the LLM usage).

KPANIC indicates that a reliable kernel crash, kernel panic, or similarly
serious kernel availability impact was identified by the classification
workflow.

AL-KERNEL base severity for this report: IMPORTANT
KPANIC detected for this report: YES
Published priority for this report (same as in Subject): IMPORTANT

These results are intended to support engineering triage. They are
machine-generated estimates, and cases marked for manual review should
be validated by a human security engineer before final disposition.
For more info read docs linked from here: https://kernelcve.org/
(and you can submit you own patch there to generate such a report
for non-existant CVE-id yet).

Note that in many cases this AI tool selects higher severity, than
real is (means you can expect Importants instead of Moderate 7.0 or
Moderates 7.0 instead of regular Moderates). If you see such cases,
please use reply email interface to add additional manual analyses
info to this particular CVE.
And please, please, let me know when you see Lows instead of Importants
or Important instead of Low (because particular for such cases I
need to tune this AI tool to make it better for this one and next similar).
My contact email for such notifications is alexanjelausa@gmail.com (and both
send reply to CVE record itself too and see "reply" button below for howto reply).