linux-kernel - Re: [PATCH v1] bcachefs: add check for btree id against max in try read node

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: <YYqtQ3LHwPRNwdc7cnA2de3ng6TXMh5UQZ5DbBC1gT4K7Ksd9n7zI6h9saJ7KAQDaBOQ7T1EVo9eEkTELyGsloBLPJqOH8eo9JrqaSEDDs0=@proton.me>
Date: Mon, 07 Oct 2024 19:15:27 +0000
From: Piotr Zalewski <pZ010001011111@...ton.me>
To: Kent Overstreet <kent.overstreet@...ux.dev>
Cc: linux-bcachefs@...r.kernel.org, linux-kernel@...r.kernel.org, skhan@...uxfoundation.org, syzbot+cf7b2215b5d70600ec00@...kaller.appspotmail.com
Subject: Re: [PATCH v1] bcachefs: add check for btree id against max in try read node

On Monday, October 7th, 2024 at 5:05 AM, Kent Overstreet <kent.overstreet@...ux.dev> wrote:

> On Mon, Oct 07, 2024 at 02:53:13AM GMT, Piotr Zalewski wrote:
> 
> > > Add check for read node's btree_id against BTREE_ID_NR_MAX in
> > > try_read_btree_node to prevent triggering EBUG_ON condition in
> > > bch2_btree_id_root[1].
> > 
> > There seems to be some kind of (pro)regression regarding this issue. Now it
> > triggers a deadlock. I also found related bug detected by syzbot[2] for
> > which someone supplied the same patch recently and it triggered the same
> > deadlock. I will look into it (perhaps simple check isn't a proper fix
> > here).
> > 
> > > [1] https://syzkaller.appspot.com/bug?extid=cf7b2215b5d70600ec00
> > 
> > [2] https://syzkaller.appspot.com/bug?extid=9f41e4b255897d99d4e9
> 
> 
> Your patch looks correct, [2] shouldn't be possible with it - and it
> appears to only be reported on upstream commits. I'll apply your patch.

Hi Kent,

Today I sat down to the other bug found by syzbot and retested it on
master, it triggers the same deadlock warning[3]. It seems like in
bch2_replicas_entry_validate mutex doesn't have to be always acquired? 
Also, I found the issue for specifically that warning[4]. The "count" is
high for the issue, is there some patch for that already pending? I 
couldn't find any.

[3] https://syzkaller.appspot.com/bug?extid=a1b59c8e1a3f022fd301
[4] https://syzkaller.appspot.com/bug?extid=4d24267b490e2b68a5fa

Best regards, Piotr Zalewski