On Sat, Sep 6, 2025, at 07:56, syzbot wrote: > syzbot suspects this issue was fixed by commit: > > commit 42b0ef01e6b5e9c77b383d32c25a0ec2a735d08a > Author: Arnd Bergmann <arnd@xxxxxxxx> > Date: Fri Jul 11 08:46:51 2025 +0000 > > block: fix FS_IOC_GETLBMD_CAP parsing in blkdev_common_ioctl() > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17c0d312580000 > start commit: ee88bddf7f2f Merge tag 'bpf-fixes' of git://git.kernel.org.. > git tree: upstream > kernel config: https://syzkaller.appspot.com/x/.config?x=28cc6f051378bb16 > dashboard link: https://syzkaller.appspot.com/bug?extid=7ca256d0da4af073b2e2 > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1026b182580000 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=159e0f0c580000 I took a look and concluded that my patch is unlikely to have fixed the issue, because: - my patch was wrong and needed another fixup on top - the reproducer and kernel log show no reference to ioctl() calls, so they do not directly interact with the code I changed. It is possible that my patch is hiding the root cause for the problem, if part of the reproducer relies on a prior call to ioctl() on a block device and this ioctl was broken by my patch. This still sounds like a long shot though, and my first guess would be that the bisection went wrong, possibly by running into more than one issue, or an unreliable reproducer. Arnd
