John Fastabend <john.fastabend@xxxxxxxxx> writes: > syzbot wrote: >> syzbot has found a reproducer for the following issue on: >> >> HEAD commit: 70ff1fe626a1 Merge tag 'docs-6.8-fixes3' of git://git.lwn... >> git tree: upstream >> console output: https://syzkaller.appspot.com/x/log.txt?x=1762045c180000 >> kernel config: https://syzkaller.appspot.com/x/.config?x=4cf52b43f46d820d >> dashboard link: https://syzkaller.appspot.com/bug?extid=8cd36f6b65f3cafd400a >> compiler: arm-linux-gnueabi-gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40 >> userspace arch: arm >> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=110cf122180000 >> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=142f6d8c180000 >> >> Downloadable assets: >> disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/8ead8862021c/non_bootable_disk-70ff1fe6.raw.xz >> vmlinux: https://storage.googleapis.com/syzbot-assets/bc398db9fd8c/vmlinux-70ff1fe6.xz >> kernel image: https://storage.googleapis.com/syzbot-assets/6d3f8b72a671/zImage-70ff1fe6.xz >> >> IMPORTANT: if you fix the issue, please add the following tag to the commit: >> Reported-by: syzbot+8cd36f6b65f3cafd400a@xxxxxxxxxxxxxxxxxxxxxxxxx >> > > I'll take a look this week if no one beats me to it. Looks like there is > a reproducer so should be able to sort it out. Took a look at the reproducer. Looks like it's creating the map with max_entries=0x80000202, which means the rounding up of the number of hash buckets overflows, and somehow the overflow check (for 0) is not working on a 32-bit machine? I guess because the roundup_power_of_two() ends up doing a (1UL << 32), which is undefined behaviour when an unsigned long is four bytes. I'll send a patch to check the value before the rounding up instead of after. -Toke
