Re: [PATCH v2] arm64: ptrace: don't warn on missing siginfo in a group-stop

[Oleg Nesterov <oleg@redhat.com>]

Will,

sorry for late reply, I was on PTO.

On 11/04, Will Deacon wrote:
>
> > > @@ -588,7 +584,7 @@ static void update_syscall_orig_x0_after_ptrace(struct task_struct *target)
> > >  	 * Don't update orig_x0 for a syscall-exit-stop, as x0 now contains the
> > >  	 * return value of the system call.
> > >  	 */
> > > -	if ((info->si_code & ~0x80) == SIGTRAP &&
> > > +	if (info && (info->si_code & ~0x80) == SIGTRAP &&
> > >  	    target->ptrace_message == PTRACE_EVENTMSG_SYSCALL_EXIT) {
> > >  		return;
> >
> > LGTM, but I don't understand this arm-specific code.
>
> Welcome to the club :)

Thank you ;)

> The original rationale is described in e057b9477232 ("arm64: syscall:
> Ensure saved x0 is kept in-sync with tracer updates"), so hopefully that
> helps to set the scene.

[...snip...]

Thanks for your explanations. Yes, I tried to read that and other commits.
The only result is that I've managed to convinced myself that more or less
I understand why 88b839ce497c and 5a87e8c7f3702 make sense.

> So that's the mess we're in and I'm all ears if there's a cleaner way to
> sort it out without breaking anything that relies on the fragile semantics
> we already have.

No, I can't suggest anything better. I think your patches and the fix from
Zhao are fine.

----------------------------------------------------------------------------
Now the question...

So we had CVE-2026-68171 and then it was rejected:
https://lore.kernel.org/linux-cve-announce/2026081123-REJECTED-f1f0@gregkh/

Now we have another one, CVE-2026-90347
https://lore.kernel.org/linux-cve-announce/2026091703-CVE-2026-90347-6f2c@gregkh/

Why?

To me the problem looks minor (security wise). Yes, a malicious debugger can
fool seccomp. So what? What is the real problem from the scurity perspective?

Oleg.