Re: [PATCH v2] rseq: fix using an uninitialized stack variable in rseq_exit_user_update

[Alexander Potapenko]

On Sat, Jun 20, 2026 at 9:51 PM Thomas Gleixner <tglx@xxxxxxxxxx> wrote:
>
> On Sat, Jun 20 2026 at 07:34, Tetsuo Handa wrote:
> > On 2026/06/20 4:32, Thomas Gleixner wrote:
> >> %On Fri, Jun 19 2026 at 21:45, Tetsuo Handa wrote:
> >>> On 2026/06/02 19:42, Peter Zijlstra wrote:
> >>>> On Tue, Jun 02, 2026 at 11:08:54AM +0800, Qing Wang wrote:
> >>>>> There is an bug which is an uninitialized stack variable use in
> >>>>> `rseq_exit_user_update()` reported by syzbot:
> >>>>>
> >>>>> BUG: KMSAN: kernel-infoleak in rseq_set_ids_get_csaddr include/linux/rseq_entry.h:502 [inline]
> >>>>>
> >>>>> The local variable:
> >>>>> ```c
> >>>>>   struct rseq_ids ids = {
> >>>>>           .cpu_id  = task_cpu(t),
> >>>>>           .mm_cid  = task_mm_cid(t),
> >>>>>           .node_id = cpu_to_node(ids.cpu_id),
> >>>>>   };
> >>>>> ```
> >>>>
> >>>> FWIW, I've no idea what that ``` nonsense is, but it does not belong in
> >>>> Changelogs. I've removed it.
> >>>>
> >>>
> >>> It seems that this problem is still happening after
> >>> commit 6d99479799c6 ("rseq: Fix using an uninitialized stack variable
> >>> in rseq_exit_user_update()") was applied. Please check.
> >>
> >> It seems is not really helpful. If you observe the problem can you
> >> please provide the full debug splat?
> >
> > Please fetch the full debug splat from https://syzkaller.appspot.com/bug?extid=185a631927096f9da2fc .
> > This problem is still happening as of commit 9ecfb2f7287a which includes commit 6d99479799c6.
>
> That's not a code problem. That's a KMSAN/compiler issue.
>
> > =====================================================
> > BUG: KMSAN: kernel-infoleak in rseq_set_ids_get_csaddr include/linux/rseq_entry.h:502 [inline]
>
> So it claims that the copy to user in rseq_set_ids_get_csaddr() is
> leaking kernel info through an unitialized variable.
>
> The ids struct is on stack and was initialized correctly ...
>
> > BUG: KMSAN: kernel-infoleak in rseq_update_usr include/linux/rseq_entry.h:536 [inline]
> > BUG: KMSAN: kernel-infoleak in rseq_exit_user_update include/linux/rseq_entry.h:645 [inline]
>
> here in rseq_exit_user_update().
>
> ffffffff90ff6433:       48 89 df                mov    %rbx,%rdi
> ffffffff90ff6436:       e8 e5 3f db f0          call   ffffffff81daa420 <task_cpu>
> ffffffff90ff643b:       89 c7                   mov    %eax,%edi
> ffffffff90ff643d:       89 45 98                mov    %eax,-0x68(%rbp)         ids.cpu_id
> ffffffff90ff6440:       8b 8b 94 0b 00 00       mov    0xb94(%rbx),%ecx
> ffffffff90ff6446:       b8 ff ff ff 9f          mov    $0x9fffffff,%eax
> ffffffff90ff644b:       21 c1                   and    %eax,%ecx
> ffffffff90ff644d:       89 4d 90                mov    %ecx,-0x70(%rbp)
> ffffffff90ff6450:       89 4d 9c                mov    %ecx,-0x64(%rbp)         ids.mm_cid
> ffffffff90ff6453:       89 7d ac                mov    %edi,-0x54(%rbp)
> ffffffff90ff6456:       e8 25 40 db f0          call   ffffffff81daa480 <cpu_to_node>
> ffffffff90ff645b:       89 45 94                mov    %eax,-0x6c(%rbp)
> ffffffff90ff645e:       89 45 a0                mov    %eax,-0x60(%rbp)         ids.node_id
> ffffffff90ff6461:       c7 45 a4 00 00 00 00    movl   $0x0,-0x5c(%rbp)
> ffffffff90ff6468:       48 8b bb 50 0b 00 00    mov    0xb50(%rbx),%rdi
> ffffffff90ff646f:       e8 9c 3e db f0          call   ffffffff81daa310 <mask_user_address>
>
> > BUG: KMSAN: kernel-infoleak in __rseq_exit_to_user_mode_restart include/linux/rseq_entry.h:674 [inline]
> > BUG: KMSAN: kernel-infoleak in rseq_exit_to_user_mode_restart include/linux/rseq_entry.h:703 [inline]
> > BUG: KMSAN: kernel-infoleak in exit_to_user_mode_loop kernel/entry/common.c:103 [inline]
> > BUG: KMSAN: kernel-infoleak in __exit_to_user_mode_prepare include/linux/irq-entry-common.h:207 [inline]
> > BUG: KMSAN: kernel-infoleak in irqentry_exit_to_user_mode_prepare include/linux/irq-entry-common.h:244 [inline]
> > BUG: KMSAN: kernel-infoleak in irqentry_exit_to_user_mode include/linux/irq-entry-common.h:315 [inline]
> > BUG: KMSAN: kernel-infoleak in irqentry_exit+0x4a6/0xa40 kernel/entry/common.c:165
> >  rseq_set_ids_get_csaddr include/linux/rseq_entry.h:502 [inline]
> >  rseq_update_usr include/linux/rseq_entry.h:536 [inline]
> >  rseq_exit_user_update include/linux/rseq_entry.h:645 [inline]
> >  __rseq_exit_to_user_mode_restart include/linux/rseq_entry.h:674 [inline]
> >  rseq_exit_to_user_mode_restart include/linux/rseq_entry.h:703 [inline]
> >  exit_to_user_mode_loop kernel/entry/common.c:103 [inline]
> >  __exit_to_user_mode_prepare include/linux/irq-entry-common.h:207 [inline]
> >  irqentry_exit_to_user_mode_prepare include/linux/irq-entry-common.h:244 [inline]
> >  irqentry_exit_to_user_mode include/linux/irq-entry-common.h:315 [inline]
> >  irqentry_exit+0x4a6/0xa40 kernel/entry/common.c:165
> >  exc_page_fault+0x7e/0xb0 arch/x86/mm/fault.c:1539
> >  asm_exc_page_fault+0x2b/0x30 arch/x86/include/asm/idtentry.h:595
>
> And then it claims that the local variable was created in a completely
> unrelated piece of code:
>
> > Local variable st.i.i created at:
> >  __do_sys_statfs fs/statfs.c:193 [inline]
> >  __se_sys_statfs fs/statfs.c:191 [inline]
> >  __x64_sys_statfs+0x73/0x200 fs/statfs.c:191
> >  x64_sys_call+0x334c/0x3ea0 arch/x86/include/generated/asm/syscalls_64.h:138
>
> The above backtrace clearly tells that the CPU cannot have been in that
> code because it's in a user mode page fault exception.
>
> > Bytes 0-3 of 4 are uninitialized
> > Memory access of size 4 starts at ffff8881192c3e78
> > Data copied to user address 00007f05e438a680
>
> The code is correct and does the right thing, so something is wrong in
> KMSAN land. Alexander?

Thanks for the heads-up.
I am currently reworking both the compiler pass and the exception
handling, which should hopefully address these problems.