From mboxrd@z Thu Jan 1 00:00:00 1970 From: AL-KERNEL To: kernel-cve@kernelcve.org Subject: [CVE-2026-89603][IMPORTANT] entry: Fix seccomp bypass after ptrace with TSYNC Date: Fri, 11 Sep 2026 20:37:39 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AL-KERNEL-CVE: CVE-2026-89603 X-AL-KERNEL-Priority: IMPORTANT X-AL-KERNEL-Severity: IMPORTANT X-AL-KERNEL-Base-Severity: IMPORTANT X-AL-KERNEL-KPANIC: YES X-AL-KERNEL-ActionableScore: 6 X-AL-KERNEL-ActionableScore-Lower: 5 X-AL-KERNEL-Commit: 459f33f82864723a7fa366cf1091d9c6c893b6b2 List-Id: 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 Signed-off-by: Thomas Gleixner 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 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).