Thank you for your contribution! Sashiko AI review found 1 potential issue(s) 
to consider:
- [High] parisc: syscall fast path exposes uninitialized pt_regs to ptrace
--

commit 38a139df8c7c61e11fc9314b5f43e371c71a8356
Author: Christian Brauner <[email protected]>

parisc: commit fds on syscall exit

This commit adds TIF_FD_SLOTS and tests it in syscall_exit once the return
value has been saved. A task that reserved descriptors calls
do_syscall_trace_exit() to commit descriptors and then continues with the
usual checks.

> diff --git a/arch/parisc/kernel/entry.S b/arch/parisc/kernel/entry.S
> index e04c5d806c105..c5807cf6fbd8d 100644
> --- a/arch/parisc/kernel/entry.S
> +++ b/arch/parisc/kernel/entry.S

[ ... ]

> @@ -1765,6 +1767,16 @@ syscall_do_signal:
>  
>       b,n     syscall_check_sig
>  
> +syscall_do_fd_slots:
> +     mfctl   %cr30,%r1
> +#ifdef CONFIG_64BIT
> +     ldo     -16(%r30),%r29                  /* Reference param save area */
> +#endif
> +     ldo     TASK_REGS(%r1),%r26             /* struct pt_regs *regs */
> +     BL      do_syscall_trace_exit,%r2

[Severity: High]
Does this expose uninitialized kernel stack memory to a tracer?

When a process executes a system call that reserves a file descriptor slot,
it enters via the fast path which only saves a minimal set of registers to
TASK_REGS. If TIF_FD_SLOTS is set, the fast path directly invokes
do_syscall_trace_exit() here before all registers (like %r3-%r18) are saved.

> +     nop
> +     b,n     syscall_check_resched
> +
>  syscall_restore:
>       mfctl   %cr30,%r1
>  

[ ... ]

> diff --git a/arch/parisc/kernel/ptrace.c b/arch/parisc/kernel/ptrace.c
> index 1d9e210702e1f..f142766792afa 100644
> --- a/arch/parisc/kernel/ptrace.c
> +++ b/arch/parisc/kernel/ptrace.c

[ ... ]

> @@ -381,6 +382,9 @@ void do_syscall_trace_exit(struct pt_regs *regs)
>       int stepping = test_thread_flag(TIF_SINGLESTEP) ||
>               test_thread_flag(TIF_BLOCKSTEP);
>  
> +     if (test_thread_flag(TIF_FD_SLOTS))
> +             fd_slots_commit(regs);
> +
>       audit_syscall_exit(regs);
>  
>  #ifdef CONFIG_HAVE_SYSCALL_TRACEPOINTS

[ ... ]

>       if (stepping || test_thread_flag(TIF_SYSCALL_TRACE))
>               ptrace_report_syscall_exit(regs, stepping);
>  }

[Severity: High]
If a tracer attaches concurrently while the process is blocked in a file
descriptor allocation syscall, setting TIF_SYSCALL_TRACE, won't this call pass
the incompletely initialized pt_regs from the fast path to the tracing
subsystem?

This could allow an unprivileged user attaching a tracer to their own process
to read uninitialized kernel memory via PTRACE_GETREGS. Also, tracer
modifications via PTRACE_SETREGS to these uninitialized registers would be
ignored because the fast path does not properly restore them before returning
to userspace.

-- 
Sashiko AI review ยท 
https://sashiko.dev/#/patchset/20260915-work-fd-reserve-unify-folded-v1-0-4d5217d6b...@kernel.org?part=14

Reply via email to