Re: [PATCH] arm64/fpsimd: ptrace: zero target's fpsimd_state, not the tracer's

[Breno Leitao <leitao@debian.org>]

Hello Mark,

On Tue, May 05, 2026 at 06:05:25PM +0100, Mark Rutland wrote:
> Hi Breno,
> 
> On Tue, May 05, 2026 at 09:02:13AM -0700, Breno Leitao wrote:
> > sve_set_common() is the backend for PTRACE_SETREGSET(NT_ARM_SVE) and
> > PTRACE_SETREGSET(NT_ARM_SSVE). Every write in the function operates on
> > the tracee (target) - except a single memset that uses current instead,
> > zeroing the tracer's saved V0-V31 / FPSR / FPCR shadow on every ptrace
> > SETREGSET call.
> 
> Sorry about this; this was my bad and definitely needs to be fixed.

No worries at all. While investigating random coredumps in the Meta fleet
with some colleagues, the randomness of the crashes reminded me of a similar
issue I encountered 10 years ago, where floating-point and vector registers
weren't being properly restored at context switch due to a kernel bug,
and created a reproducer in commit 77fad8bfb1d2f ("selftests/powerpc:
Check FP/VEC on exception in TM"). So, this class of bugs is not
special, although *very* hard to debug.

> > Due to FPSIMD lazy save/restore the wipe only takes effect when the
> > tracer's CPU FPSIMD binding is dropped after the memset; the next
> > return to userspace then reloads V0-V31, FPSR and FPCR as zero. No
> > signal is raised and ptrace() returns success.
> 
> You're right that the corruption of the tracer's state is often masked,
> but I don't think the last paragraph describes the circumstances
> entirely accurately (e.g. if the binding is lost *before* the memset(),
> the issue can still occur).
> 
> I think it would be better to say:
> 
>   The corruption of the tracer's saved FPSIMD state is not always
>   observable. Where the tracer's state is live on a CPU, this may reused
>   without loading the corrupted state from memory, and will eventually
>   be written back over the corrupted state. Where the tracer's state is
>   saved in SVE_PT_REGS_SVE format, only the FPSR and FPCR are clobbered,
>   and the effective copy of the vectors is in the task's sve_state.

Ack!

> > Fixes: 316283f276eb ("arm64/fpsimd: ptrace: Consistently handle partial writes to NT_ARM_(S)SVE")
> > Signed-off-by: Breno Leitao <leitao@debian.org>
> 
> This will need to be Cc'd to stable.
> 
> With the fixups above (which I assume Catalin or Will can handle):
> 
> Acked-by: Mark Rutland <mark.rutland@arm.com>

Thank you for the review. I won't respin it, assuming Catalin or Will
can handle the message rewrite.

Thanks again!
--breno