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:
1. kernel_execve does not currently clear integer registers, so the starting
register state for PID 1 and other user processes started by the kernel has
sp = user stack, gp = kernel __global_pointer$, all other integer registers
zeroed by the memset in the patch comment.
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.
2. ptrace(PTRACE_GETREGSET): you can PTRACE_ATTACH to a user_mode_helper thread
before it execs, but ptrace requires SIGSTOP to be delivered which can only
happen at user/kernel boundaries.
3. /proc/*/task/*/syscall: this is perfectly happy to read pt_regs for
user_mode_helpers before the exec completes, but gp is not one of the
registers it returns.
4. PERF_SAMPLE_REGS_USER: LOCKDOWN_PERF normally prevents access to kernel
addresses via PERF_SAMPLE_REGS_INTR, but due to this bug kernel addresses
are also exposed via PERF_SAMPLE_REGS_USER which is permitted under
LOCKDOWN_PERF. I have not attempted to write exploit code.
5. Much of the tracing infrastructure allows access to user registers. I have
not attempted to determine which forms of tracing allow access to user
registers without already allowing access to kernel registers.
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:
1. kernel_execve does not currently clear integer registers, so the starting
register state for PID 1 and other user processes started by the kernel has
sp = user stack, gp = kernel __global_pointer$, all other integer registers
zeroed by the memset in the patch comment.
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.
2. ptrace(PTRACE_GETREGSET): you can PTRACE_ATTACH to a user_mode_helper thread
before it execs, but ptrace requires SIGSTOP to be delivered which can only
happen at user/kernel boundaries.
3. /proc/*/task/*/syscall: this is perfectly happy to read pt_regs for
user_mode_helpers before the exec completes, but gp is not one of the
registers it returns.
4. PERF_SAMPLE_REGS_USER: LOCKDOWN_PERF normally prevents access to kernel
addresses via PERF_SAMPLE_REGS_INTR, but due to this bug kernel addresses
are also exposed via PERF_SAMPLE_REGS_USER which is permitted under
LOCKDOWN_PERF. I have not attempted to write exploit code.
5. Much of the tracing infrastructure allows access to user registers. I have
not attempted to determine which forms of tracing allow access to user
registers without already allowing access to kernel registers.
Metrics
Affected Vendors & Products
Advisories
| Source | ID | Title |
|---|---|---|
Debian DLA |
DLA-3842-1 | linux-5.10 security update |
Ubuntu USN |
USN-6893-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-6893-2 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-6893-3 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-6898-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-6898-2 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-6898-3 | Linux kernel kernel vulnerabilities |
Ubuntu USN |
USN-6898-4 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-6917-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-6918-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-6919-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-6927-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7019-1 | Linux kernel vulnerabilities |
Fixes
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
References
History
Fri, 22 Nov 2024 12:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
|
Tue, 05 Nov 2024 10:45:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
|
Projects
Sign in to view the affected projects.
Status: PUBLISHED
Assigner: Linux
Published:
Updated: 2025-05-04T09:07:18.449Z
Reserved: 2024-05-17T13:50:33.108Z
Link: CVE-2024-35871
Updated: 2024-06-17T17:38:52.800Z
Status : Awaiting Analysis
Published: 2024-05-19T09:15:08.507
Modified: 2024-11-21T09:21:05.780
Link: CVE-2024-35871
OpenCVE Enrichment
Updated: 2025-07-12T22:31:25Z
Weaknesses
No weakness.
Debian DLA
Ubuntu USN