On Mon, Aug 31, 2026 at 02:34:10PM +0530, Shrikanth Hegde wrote:
>
>
> On 8/31/26 10:09 AM, Mukesh Kumar Chaurasiya wrote:
> > On Fri, Aug 28, 2026 at 11:08:11AM +0530, Shrikanth Hegde wrote:
> > > Shivaprasad reported a boot failure due to userspace processes crash on
> > > abort() from libc.so.6. It was bisected to merge request
> > > commit '3424d8c18a7d ("Merge tag 'core-entry-2026-08-17' of
> > > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip")'
> > >
> > > Upon checking the merge, when syscall_enter_from_user_mode_randomize_stack
> > > fails, which could happen when a tracer like seccomp or ptrace intercepts
> > > and skips the syscall, the code returns to userspace immediately without
> > > clearing the intermediate flag which was set.
> > >
> > > When the next syscall is made, it immediately aborts the valid syscall
> > > since the flag is still set. Hence clear the flag on occurrence of first
> > > failure.
> > >
> > > Reported-by: Shivaprasad G Bhat <[email protected]>
> > > Closes:
> > > https://lore.kernel.org/all/[email protected]/
> > > Fixes: 3424d8c18a7d ("Merge tag 'core-entry-2026-08-17' of
> > > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip")
> > > Signed-off-by: Shrikanth Hegde <[email protected]>
> > > ---
> > > PS: I have kept the block below since earlier code was checking it
> > > regardless of result of syscall_enter_from_user_mode. If it turns out
> > > to be a redundant, it can be removed later.
> > >
> > I think it is redundant as of now. The TIF_SYSCALL_RET flag is set when
> > error is set by the ptrace or seccomp, If the error value is set then
> > the syscall_enter_from_user_mode_randomize_stack will return false.
> > Hence the next check will become redundant.
> >
> > I also see that TIF_SYSCALL_RET is also set when processing the ptrace
> > syscall, Which can leave the flag set for next syscall execution. Which
> > can again trigger the same issue.
> >
>
> I believe it is a pre-existing bug which can be fixed independent of this
> issue.
> Since merge request broke the userspace it is better we fix it right away and
> this pre-existing issue fix can be done subsequently.
>
> No?
>
Agreed.
Sure we can send that as a separate fix.
With that,
Reviewed-by: Mukesh Kumar Chaurasiya (IBM) <[email protected]>
Regards
Mukesh.
> > Regards,
> > Mukesh
> > > arch/powerpc/kernel/syscall.c | 4 +++-
> > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/powerpc/kernel/syscall.c b/arch/powerpc/kernel/syscall.c
> > > index 4916c205c4bb..fbefe1927b10 100644
> > > --- a/arch/powerpc/kernel/syscall.c
> > > +++ b/arch/powerpc/kernel/syscall.c
> > > @@ -18,8 +18,10 @@ notrace long system_call_exception(struct pt_regs
> > > *regs, unsigned long r0)
> > > long ret;
> > > syscall_fn f;
> > > - if (unlikely(!syscall_enter_from_user_mode_randomize_stack(regs, &r0)))
> > > + if (unlikely(!syscall_enter_from_user_mode_randomize_stack(regs, &r0)))
> > > {
> > > + clear_thread_flag(TIF_SYSCALL_RET);
> > > return syscall_get_error(current, regs);
> > > + }
> > > if (unlikely(test_and_clear_thread_flag(TIF_SYSCALL_RET)))
> > > return syscall_get_error(current, regs);
> > > --
> > > 2.47.3
> > >
>
