lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 27 May 2024 17:47:03 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: syzbot <syzbot+97f26f162079653e77b8@...kaller.appspotmail.com>,
 bp@...en8.de, dave.hansen@...ux.intel.com, hpa@...or.com,
 linux-kernel@...r.kernel.org, mingo@...hat.com,
 syzkaller-bugs@...glegroups.com, x86@...nel.org
Subject: Re: [syzbot] [kernel?] WARNING: locking bug in collect_percpu_times

On Sat, May 25 2024 at 14:52, syzbot wrote:
> HEAD commit:    2a8120d7b482 Merge tag 's390-6.10-2' of git://git.kernel.o..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=145dd452980000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=5dd4fde1337a9e18
> dashboard link: https://syzkaller.appspot.com/bug?extid=97f26f162079653e77b8
> compiler:       gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
> userspace arch: i386
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> Downloadable assets:
> disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/7bc7510fe41f/non_bootable_disk-2a8120d7.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/78c72ae6bdaf/vmlinux-2a8120d7.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/99dbb805b738/bzImage-2a8120d7.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+97f26f162079653e77b8@...kaller.appspotmail.com
>
> ------------[ cut here ]------------
> Looking for class "->pcpu, cpu)->seq" with key __key.9, but found a different class "&per_cpu_ptr(group->pcpu, cpu)->seq" with the same key

This is a pattern I've seen in quite some recent syzbot reports where
the class string is a subset of the recorded string.

I have no idea how that can happen, but it smells like data corruption
of some sort.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ