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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.