Re: [PATCH RFC POC 14/50] parisc: commit fds on syscall exit
From: sashiko-bot@kernel.org
Date: 2026-09-15 11:59:56
Also in:
bpf, dri-devel, io-uring, kexec, kvm, linux-alpha, linux-arm-kernel, linux-arm-msm, linux-fsdevel, linux-gpio, linux-hyperv, linux-m68k, linux-mips, linux-mm, linux-sh, linux-um, lkml, sparclinux, virtualization
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 [off-list ref] 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.
quoted hunk ↗ jump to hunk
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
[ ... ]
quoted hunk ↗ jump to hunk
@@ -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
[ ... ]
quoted hunk ↗ jump to hunk
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
[ ... ]
quoted hunk ↗ jump to hunk
@@ -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-4d5217d6b246@kernel.org?part=14