From: Thomas Gleixner <tglx@kernel.org>
To: syzbot <syzbot+411634dace73dad6f4d4@syzkaller.appspotmail.com>,
linux-kernel@vger.kernel.org, luto@kernel.org,
peterz@infradead.org, syzkaller-bugs@googlegroups.com
Subject: Re: [syzbot] [kernel?] KMSAN: kernel-infoleak in exc_page_fault
Date: Thu, 25 Jun 2026 09:07:23 +0200 [thread overview]
Message-ID: <871pdvksic.ffs@fw13> (raw)
In-Reply-To: <6a3c7f84.43b4ff68.30a095.0003.GAE@google.com>
#syz set subsystems: kasan
On Wed, Jun 24 2026 at 18:08, syzbot wrote:
> syzbot found the following issue on:
>
> HEAD commit: 9ecfb2f7287a Merge tag 'trace-ring-buffer-v7.2' of git://g..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1471e8ea580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=a9e1383387f0e112
> dashboard link: https://syzkaller.appspot.com/bug?extid=411634dace73dad6f4d4
> compiler: Debian clang version 22.1.6 (++20260514074242+fc4aad7b5db3-1~exp1~20260514074407.73), Debian LLD 22.1.6
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/c8d222bd96ba/disk-9ecfb2f7.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/629368d40b7e/vmlinux-9ecfb2f7.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/156086f5f12a/bzImage-9ecfb2f7.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+411634dace73dad6f4d4@syzkaller.appspotmail.com
As I already explained here:
https://lore.kernel.org/871pe1ng7m.ffs@fw13
this is a KMSAN/compiler bug:
> BUG: KMSAN: kernel-infoleak in rseq_set_ids_get_csaddr include/linux/rseq_entry.h:502 [inline]
> 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]
> 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
> exc_page_fault+0x7e/0xb0 arch/x86/mm/fault.c:1539
> asm_exc_page_fault+0x2b/0x30 arch/x86/include/asm/idtentry.h:595
There was a real issue before 6d99479799c6 got applied, but KMSAN still
claims that a local variable which is completely unrelated and was
created in a (previous) syscall is the problem:
> 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
That's clearly some stale information.
> Bytes 0-3 of 4 are uninitialized
> Memory access of size 4 starts at ffff88811856be78
> Data copied to user address 00007ff99a04cac0
The local variable access in rseq_set_ids_get_csaddr() is
ids->cpu_id. ids is a stack variable created _and_ correctly initialized
in rseq_exit_user_update().
prev parent reply other threads:[~2026-06-25 7:07 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-25 1:08 [syzbot] [kernel?] KMSAN: kernel-infoleak in exc_page_fault syzbot
2026-06-25 7:07 ` Thomas Gleixner [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871pdvksic.ffs@fw13 \
--to=tglx@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=peterz@infradead.org \
--cc=syzbot+411634dace73dad6f4d4@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox