In the Linux kernel, the following vulnerability has been resolved:
riscv: process: Fix kernel gp leakage
childregs represents the registers which are active for the new thread in user context. For a kernel thread, childregs->gp is never used since the kernel gp is not touched by switch_to. For a user mode helper, the gp value can be observed in user space after execve or possibly by other means.
[From the email thread]
The /* Kernel thread */ comment is somewhat inaccurate in that it is also used for user_mode_helper threads, which exec a user process, e.g. /sbin/init or when /proc/sys/kernel/core_pattern is a pipe. Such threads do not have PF_KTHREAD set and are valid targets for ptrace etc. even before they exec.
childregs is the *user* context during syscall execution and it is observable from userspace in at least five ways:
- kernel_execve does not currently clear integer registers, so the starting
This is a bug in its own right, but I'm unwilling to bet that it is the only way to exploit the issue addressed by this patch.
- ptrace(PTRACE_GETREGSET): you can PTRACE_ATTACH to a user_mode_helper thread
- /proc/*/task/*/syscall: this is perfectly happy to read pt_regs for
- PERF_SAMPLE_REGS_USER: LOCKDOWN_PERF normally prevents access to kernel
- Much of the tracing infrastructure allows access to user registers. I have