CVE-2026-90339: powerpc/syscall: Fix syscall skip handling for seccomp and ptrace
In the Linux kernel, the following vulnerability has been resolved:
powerpc/syscall: Fix syscall skip handling for seccomp and ptrace
After enabling GENERICENTRY on PowerPC, syscallenterfromusermode() returns -1 as a sentinel to signal that seccomp or ptrace has intercepted the syscall and already set a return value via syscallsetreturnvalue(). systemcallexception() was not handling this sentinel, and since -1UL is >= NRsyscalls, the code fell into the out-of-range path and returned -ENOSYS, overwriting the errno already placed in regs->gpr[3].
The naive fix of checking r0 == -1L before the NRsyscalls bounds check is ambiguous: a user legitimately calling syscall(-1) also produces r0 == -1L, and a tracer intercepting such a call would have its injected return value silently discarded.
Fix this by introducing a thread flag that is set whenever syscallsetreturnvalue() explicitly updates the return value. In systemcallexception(), check and clear this flag before dispatching the syscall, and return the preset value directly when it is present. This ensures that an explicitly supplied return value always suppresses syscall execution, regardless of the syscall number.
This handles all seccomp actions correctly:
- SECCOMPRETERRNO, SECCOMPRETTRACE (no tracer), SECCOMPRETUSERNOTIF: all call syscallsetreturnvalue(), flag is set, injected value returned. - SECCOMPRETTRAP, SECCOMPRETKILL: call syscallrollback() and deliver a signal; flag is not set, but the process is dying so the return value is irrelevant.
The fix covers both ppc32 and ppc64 with no #ifdefs.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Apply the kernel code fix for 'powerpc/syscall: Fix syscall skip handling for seccomp and ptrace' so that system_call_exception() checks and clears the thread flag before dispatching the syscall, and returns the preset value directly when present. This prevents discarding an explicitly supplied return value and handles all seccomp actions correctly (signal vs. syscall_set_return_value(), etc.).
Linux kernel (powerpc/syscall) seccomp/ptrace syscall skip handling = Introduce a thread flag that is set when an intercepted return sentinel is returned (e.g., -1UL/-1L) and cleared in system_call_exception() before dispatch
Event History
Frequently Asked Questions
Which systems and workloads are exposed to this issue?
The issue affects PowerPC Linux kernel syscall handling after GENERIC_ENTRY is enabled. It is triggered when seccomp or ptrace intercepts a syscall and explicitly supplies a return value.
What symptom would indicate that the issue is occurring?
A return value placed by seccomp or ptrace can be overwritten with -ENOSYS. This can occur because the syscall-entry path treats the -1 sentinel as an out-of-range syscall number.
Does the issue also affect traced attempts to invoke syscall number -1?
Yes. A traced syscall(-1) is specifically ambiguous under the naive sentinel check, and a tracer-injected return value could be silently discarded.