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

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

[Qing Wang]

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),
	};
```
According to the C standard, the evaluation order of expressions in an
initializer list is indeterminately sequenced. The compiler (Clang, in this
KMSAN build) evaluates `cpu_to_node(ids.cpu_id)` *before* `ids.cpu_id` is
initialized with `task_cpu(t)`.

This is fixed by moving the assignment of ids.node_id outside the structure
initialization.

Reported-by: syzbot+185a631927096f9da2fc@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=185a631927096f9da2fc
Fixes: 82f572449cfe ("rseq: Implement read only ABI enforcement for optimized RSEQ V2 mode")
Signed-off-by: Qing Wang <wangqing7171@gmail.com>
---
 include/linux/rseq_entry.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/rseq_entry.h b/include/linux/rseq_entry.h
index 63bc72086e75..e05f4c18f39e 100644
--- a/include/linux/rseq_entry.h
+++ b/include/linux/rseq_entry.h
@@ -638,8 +638,8 @@ static __always_inline bool rseq_exit_user_update(struct pt_regs *regs, struct t
 	struct rseq_ids ids = {
 		.cpu_id	 = task_cpu(t),
 		.mm_cid	 = task_mm_cid(t),
-		.node_id = cpu_to_node(ids.cpu_id),
 	};
+	ids.node_id = cpu_to_node(ids.cpu_id);
 
 	return rseq_update_usr(t, regs, &ids);
 efault:
-- 
2.34.1

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

[Mathieu Desnoyers]

On 2026-05-31 22:13, 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),
> 	};
> ```
> According to the C standard, the evaluation order of expressions in an
> initializer list is indeterminately sequenced. The compiler (Clang, in this
> KMSAN build) evaluates `cpu_to_node(ids.cpu_id)` *before* `ids.cpu_id` is
> initialized with `task_cpu(t)`.
> 
> This is fixed by moving the assignment of ids.node_id outside the structure
> initialization.
> 
> Reported-by: syzbot+185a631927096f9da2fc@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=185a631927096f9da2fc
> Fixes: 82f572449cfe ("rseq: Implement read only ABI enforcement for optimized RSEQ V2 mode")
> Signed-off-by: Qing Wang <wangqing7171@gmail.com>
> ---
>   include/linux/rseq_entry.h | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/rseq_entry.h b/include/linux/rseq_entry.h
> index 63bc72086e75..e05f4c18f39e 100644
> --- a/include/linux/rseq_entry.h
> +++ b/include/linux/rseq_entry.h
> @@ -638,8 +638,8 @@ static __always_inline bool rseq_exit_user_update(struct pt_regs *regs, struct t
>   	struct rseq_ids ids = {
>   		.cpu_id	 = task_cpu(t),
>   		.mm_cid	 = task_mm_cid(t),
> -		.node_id = cpu_to_node(ids.cpu_id),
>   	};
> +	ids.node_id = cpu_to_node(ids.cpu_id);

I find the fix odd. How about:

int cpu = task_cpu(t);
struct rseq_ids ids = {
	.cpu_id = cpu,
	.mm_cid = task_mm_cid(t),
	.node_id = cpu_to_node(cpu),
};

instead ?

Thanks,

Mathieu

>   
>   	return rseq_update_usr(t, regs, &ids);
>   efault:


-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com

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

[Peter Zijlstra]

On Mon, Jun 01, 2026 at 09:59:35AM -0400, Mathieu Desnoyers wrote:
> On 2026-05-31 22:13, 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),
> > 	};
> > ```
> > According to the C standard, the evaluation order of expressions in an
> > initializer list is indeterminately sequenced. The compiler (Clang, in this
> > KMSAN build) evaluates `cpu_to_node(ids.cpu_id)` *before* `ids.cpu_id` is
> > initialized with `task_cpu(t)`.

W.T.F. would they (C committee) do that :-(, and since this is
apparently a known thing, why aren't the compilers issuing WARNs about
this pattern?

Clearly any non address-of self reference in a struct initializer is
buggered.

And ideally it would actually observe the data-dependency and respect
it, irrespective of the lunacy of the C standard.

> > This is fixed by moving the assignment of ids.node_id outside the structure
> > initialization.
> > 
> > Reported-by: syzbot+185a631927096f9da2fc@syzkaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=185a631927096f9da2fc
> > Fixes: 82f572449cfe ("rseq: Implement read only ABI enforcement for optimized RSEQ V2 mode")
> > Signed-off-by: Qing Wang <wangqing7171@gmail.com>
> > ---
> >   include/linux/rseq_entry.h | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/include/linux/rseq_entry.h b/include/linux/rseq_entry.h
> > index 63bc72086e75..e05f4c18f39e 100644
> > --- a/include/linux/rseq_entry.h
> > +++ b/include/linux/rseq_entry.h
> > @@ -638,8 +638,8 @@ static __always_inline bool rseq_exit_user_update(struct pt_regs *regs, struct t
> >   	struct rseq_ids ids = {
> >   		.cpu_id	 = task_cpu(t),
> >   		.mm_cid	 = task_mm_cid(t),
> > -		.node_id = cpu_to_node(ids.cpu_id),
> >   	};
> > +	ids.node_id = cpu_to_node(ids.cpu_id);
> 
> I find the fix odd. How about:
> 
> int cpu = task_cpu(t);
> struct rseq_ids ids = {
> 	.cpu_id = cpu,
> 	.mm_cid = task_mm_cid(t),
> 	.node_id = cpu_to_node(cpu),
> };
> 
> instead ?

Yes, much saner.

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

[Qing Wang]

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),
	};
```
According to the C standard, the evaluation order of expressions in an
initializer list is indeterminately sequenced. The compiler (Clang, in this
KMSAN build) evaluates `cpu_to_node(ids.cpu_id)` *before* `ids.cpu_id` is
initialized with `task_cpu(t)`.

This is fixed by moving the assignment of ids.node_id outside the structure
initialization.

Reported-by: syzbot+185a631927096f9da2fc@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=185a631927096f9da2fc
Fixes: 82f572449cfe ("rseq: Implement read only ABI enforcement for optimized RSEQ V2 mode")
Signed-off-by: Qing Wang <wangqing7171@gmail.com>
---
 include/linux/rseq_entry.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/linux/rseq_entry.h b/include/linux/rseq_entry.h
index 63bc72086e75..ed9da6e41a2a 100644
--- a/include/linux/rseq_entry.h
+++ b/include/linux/rseq_entry.h
@@ -635,10 +635,11 @@ static __always_inline bool rseq_exit_user_update(struct pt_regs *regs, struct t
 		return true;
 	}
 
+	int cpu = task_cpu(t);
 	struct rseq_ids ids = {
-		.cpu_id	 = task_cpu(t),
+		.cpu_id	 = cpu,
 		.mm_cid	 = task_mm_cid(t),
-		.node_id = cpu_to_node(ids.cpu_id),
+		.node_id = cpu_to_node(cpu),
 	};
 
 	return rseq_update_usr(t, regs, &ids);
-- 
2.34.1

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

[Mark Rutland]

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),
> 	};
> ```
> According to the C standard, the evaluation order of expressions in an
> initializer list is indeterminately sequenced. The compiler (Clang, in this
> KMSAN build) evaluates `cpu_to_node(ids.cpu_id)` *before* `ids.cpu_id` is
> initialized with `task_cpu(t)`.
> 
> This is fixed by moving the assignment of ids.node_id outside the structure
> initialization.
> 
> Reported-by: syzbot+185a631927096f9da2fc@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=185a631927096f9da2fc
> Fixes: 82f572449cfe ("rseq: Implement read only ABI enforcement for optimized RSEQ V2 mode")
> Signed-off-by: Qing Wang <wangqing7171@gmail.com>

FWIW, this looks sane to me, so:

Acked-by: Mark Rutland <mark.rutland@arm.com>

Mark.

> ---
>  include/linux/rseq_entry.h | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/rseq_entry.h b/include/linux/rseq_entry.h
> index 63bc72086e75..ed9da6e41a2a 100644
> --- a/include/linux/rseq_entry.h
> +++ b/include/linux/rseq_entry.h
> @@ -635,10 +635,11 @@ static __always_inline bool rseq_exit_user_update(struct pt_regs *regs, struct t
>  		return true;
>  	}
>  
> +	int cpu = task_cpu(t);
>  	struct rseq_ids ids = {
> -		.cpu_id	 = task_cpu(t),
> +		.cpu_id	 = cpu,
>  		.mm_cid	 = task_mm_cid(t),
> -		.node_id = cpu_to_node(ids.cpu_id),
> +		.node_id = cpu_to_node(cpu),
>  	};
>  
>  	return rseq_update_usr(t, regs, &ids);
> -- 
> 2.34.1
> 

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

[Peter Zijlstra]

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.

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

[Tetsuo Handa]

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.

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

[Thomas Gleixner]

%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?

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

[Tetsuo Handa]

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.

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

[Thomas Gleixner]

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,

        tglx