CVE-2024-35871

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: process: Fix kernel gp leakage<br /> <br /> childregs represents the registers which are active for the new thread<br /> in user context. For a kernel thread, childregs-&gt;gp is never used since<br /> the kernel gp is not touched by switch_to. For a user mode helper, the<br /> gp value can be observed in user space after execve or possibly by other<br /> means.<br /> <br /> [From the email thread]<br /> <br /> The /* Kernel thread */ comment is somewhat inaccurate in that it is also used<br /> for user_mode_helper threads, which exec a user process, e.g. /sbin/init or<br /> when /proc/sys/kernel/core_pattern is a pipe. Such threads do not have<br /> PF_KTHREAD set and are valid targets for ptrace etc. even before they exec.<br /> <br /> childregs is the *user* context during syscall execution and it is observable<br /> from userspace in at least five ways:<br /> <br /> 1. kernel_execve does not currently clear integer registers, so the starting<br /> register state for PID 1 and other user processes started by the kernel has<br /> sp = user stack, gp = kernel __global_pointer$, all other integer registers<br /> zeroed by the memset in the patch comment.<br /> <br /> This is a bug in its own right, but I&amp;#39;m unwilling to bet that it is the only<br /> way to exploit the issue addressed by this patch.<br /> <br /> 2. ptrace(PTRACE_GETREGSET): you can PTRACE_ATTACH to a user_mode_helper thread<br /> before it execs, but ptrace requires SIGSTOP to be delivered which can only<br /> happen at user/kernel boundaries.<br /> <br /> 3. /proc/*/task/*/syscall: this is perfectly happy to read pt_regs for<br /> user_mode_helpers before the exec completes, but gp is not one of the<br /> registers it returns.<br /> <br /> 4. PERF_SAMPLE_REGS_USER: LOCKDOWN_PERF normally prevents access to kernel<br /> addresses via PERF_SAMPLE_REGS_INTR, but due to this bug kernel addresses<br /> are also exposed via PERF_SAMPLE_REGS_USER which is permitted under<br /> LOCKDOWN_PERF. I have not attempted to write exploit code.<br /> <br /> 5. Much of the tracing infrastructure allows access to user registers. I have<br /> not attempted to determine which forms of tracing allow access to user<br /> registers without already allowing access to kernel registers.