| Message ID | 20221029113450.4027-1-jszhang@kernel.org (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 6510c78490c490a6636e48b61eeaa6fb65981f4b |
| Delegated to: | Palmer Dabbelt |
| Headers | show |
| Series | riscv: process: fix kernel info leakage | expand |
| Context | Check | Description |
|---|---|---|
| conchuod/patch_count | success | Link |
| conchuod/fixes_present | success | Fixes tag not required for -next series |
| conchuod/tree_selection | success | Guessed tree name to be for-next |
| conchuod/cover_letter | success | Single patches do not need cover letters |
| conchuod/kdoc | success | Errors and warnings before: 0 this patch: 0 |
| conchuod/source_inline | success | Was 0 now: 0 |
| conchuod/verify_signedoff | success | Signed-off-by tag matches author and committer |
| conchuod/cc_maintainers | warning | 2 maintainers not CCed: ebiederm@xmission.com anup@brainfault.org |
| conchuod/module_param | success | Was 0 now: 0 |
| conchuod/verify_fixes | success | Fixes tag looks correct |
| conchuod/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 8 lines checked |
| conchuod/header_inline | success | No static functions without inline keyword in header files |
| conchuod/build_warn_rv64 | fail | Errors and warnings before: 0 this patch: 0 |
On Sat, Oct 29, 2022 at 7:44 PM Jisheng Zhang <jszhang@kernel.org> wrote: > > thread_struct's s[12] may contain random kernel memory content, which > may be finally leaked to userspace. This is a security hole. Fix it > by clearing the s[12] array in thread_struct when fork. > > As for kthread case, it's better to clear the s[12] array as well. > > Fixes: 7db91e57a0ac ("RISC-V: Task implementation") > Signed-off-by: Jisheng Zhang <jszhang@kernel.org> > --- > > Previously, it's one of the series of "riscv: entry: further clean up > and VMAP_STACK fix". This is a fix, so I move it out of the series and > send it separately > > arch/riscv/kernel/process.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c > index ceb9ebab6558..52002d54b163 100644 > --- a/arch/riscv/kernel/process.c > +++ b/arch/riscv/kernel/process.c > @@ -164,6 +164,8 @@ int copy_thread(struct task_struct *p, const struct kernel_clone_args *args) > unsigned long tls = args->tls; > struct pt_regs *childregs = task_pt_regs(p); > > + memset(&p->thread.s, 0, sizeof(p->thread.s)); Tested-by: Guo Ren <guoren@kernel.org> > + > /* p->thread holds context to be restored by __switch_to() */ > if (unlikely(args->fn)) { > /* Kernel thread */ > -- > 2.37.2 >
On Sat, Oct 29, 2022 at 07:34:50PM +0800, Jisheng Zhang wrote: > thread_struct's s[12] may contain random kernel memory content, which > may be finally leaked to userspace. This is a security hole. Fix it > by clearing the s[12] array in thread_struct when fork. > > As for kthread case, it's better to clear the s[12] array as well. > > Fixes: 7db91e57a0ac ("RISC-V: Task implementation") > Signed-off-by: Jisheng Zhang <jszhang@kernel.org> > --- > > Previously, it's one of the series of "riscv: entry: further clean up > and VMAP_STACK fix". This is a fix, so I move it out of the series and > send it separately Should this not be carrying a R-b from Guo Ren from that series? https://lore.kernel.org/linux-riscv/CAJF2gTSdVyAaM12T+7kXAdRPGS4VyuO08X1c7paE-n4Fr8OtRA@mail.gmail.com/ > > arch/riscv/kernel/process.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c > index ceb9ebab6558..52002d54b163 100644 > --- a/arch/riscv/kernel/process.c > +++ b/arch/riscv/kernel/process.c > @@ -164,6 +164,8 @@ int copy_thread(struct task_struct *p, const struct kernel_clone_args *args) > unsigned long tls = args->tls; > struct pt_regs *childregs = task_pt_regs(p); > > + memset(&p->thread.s, 0, sizeof(p->thread.s)); > + > /* p->thread holds context to be restored by __switch_to() */ > if (unlikely(args->fn)) { > /* Kernel thread */ > -- > 2.37.2 >
On Sat, 29 Oct 2022 19:34:50 +0800, Jisheng Zhang wrote: > thread_struct's s[12] may contain random kernel memory content, which > may be finally leaked to userspace. This is a security hole. Fix it > by clearing the s[12] array in thread_struct when fork. > > As for kthread case, it's better to clear the s[12] array as well. > > > [...] Applied, thanks! [1/1] riscv: process: fix kernel info leakage https://git.kernel.org/palmer/c/6510c78490c4 Best regards,
Hello: This patch was applied to riscv/linux.git (fixes) by Palmer Dabbelt <palmer@rivosinc.com>: On Sat, 29 Oct 2022 19:34:50 +0800 you wrote: > thread_struct's s[12] may contain random kernel memory content, which > may be finally leaked to userspace. This is a security hole. Fix it > by clearing the s[12] array in thread_struct when fork. > > As for kthread case, it's better to clear the s[12] array as well. > > Fixes: 7db91e57a0ac ("RISC-V: Task implementation") > Signed-off-by: Jisheng Zhang <jszhang@kernel.org> > > [...] Here is the summary with links: - riscv: process: fix kernel info leakage https://git.kernel.org/riscv/c/6510c78490c4 You are awesome, thank you!
diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c index ceb9ebab6558..52002d54b163 100644 --- a/arch/riscv/kernel/process.c +++ b/arch/riscv/kernel/process.c @@ -164,6 +164,8 @@ int copy_thread(struct task_struct *p, const struct kernel_clone_args *args) unsigned long tls = args->tls; struct pt_regs *childregs = task_pt_regs(p); + memset(&p->thread.s, 0, sizeof(p->thread.s)); + /* p->thread holds context to be restored by __switch_to() */ if (unlikely(args->fn)) { /* Kernel thread */
thread_struct's s[12] may contain random kernel memory content, which may be finally leaked to userspace. This is a security hole. Fix it by clearing the s[12] array in thread_struct when fork. As for kthread case, it's better to clear the s[12] array as well. Fixes: 7db91e57a0ac ("RISC-V: Task implementation") Signed-off-by: Jisheng Zhang <jszhang@kernel.org> --- Previously, it's one of the series of "riscv: entry: further clean up and VMAP_STACK fix". This is a fix, so I move it out of the series and send it separately arch/riscv/kernel/process.c | 2 ++ 1 file changed, 2 insertions(+)