linux-kernel - Re: [syzbot] [bcachefs?] kernel BUG in bch2_stripe

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]

Message-ID: <5eckzshpqknmjqjakakru6npjxwj74xkimiiueebeg3aufovzf@zdwkxn4eblun>
Date: Sun, 27 Apr 2025 15:16:35 -0400
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: syzbot <syzbot+f57d864a5d6eff90da3b@...kaller.appspotmail.com>
Cc: bfoster@...hat.com, linux-bcachefs@...r.kernel.org, 
	linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [bcachefs?] kernel BUG in bch2_stripe_validate

On Sun, Apr 27, 2025 at 08:10:03AM -0700, syzbot wrote:
> syzbot suspects this issue was fixed by commit:
> 
> commit 71f8e806a5e4edada72456ee3b2e2d7eab6fadee
> Author: Kent Overstreet <kent.overstreet@...ux.dev>
> Date:   Fri Apr 18 16:49:00 2025 +0000
> 
>     bcachefs: Stricter checks on "key allowed in this btree"
> 
> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=16b9e270580000
> start commit:   ccb98ccef0e5 Merge tag 'platform-drivers-x86-v6.13-4' of g..
> git tree:       upstream
> kernel config:  https://syzkaller.appspot.com/x/.config?x=ba7cde9482d6bb6
> dashboard link: https://syzkaller.appspot.com/bug?extid=f57d864a5d6eff90da3b
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=131666df980000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=10556ac4580000
> 
> If the result looks correct, please mark the issue as fixed by replying with:

#syz fix: bcachefs: Stricter checks on "key allowed in this btree"

We had a similar one where syzbot manager to come up with a reflink
pointer in the inodes btree - triggers and validation get very confused
at that sort of thing, in particular because whether or not k->size
should be zero is btree specific