linux-kernel - Re: [syzbot] [hfs] general protection fault in tomoyo_check

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: Fri, 15 Mar 2024 14:29:17 +0100
From: Christian Brauner <brauner@...nel.org>
To: Jan Kara <jack@...e.cz>
Cc: Aleksandr Nogikh <nogikh@...gle.com>, 
	syzbot <syzbot+28aaddd5a3221d7fd709@...kaller.appspotmail.com>, axboe@...nel.dk, jmorris@...ei.org, 
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-security-module@...r.kernel.org, paul@...l-moore.com, serge@...lyn.com, 
	syzkaller-bugs@...glegroups.com, Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>, 
	Dmitry Vyukov <dvyukov@...gle.com>
Subject: Re: [syzbot] [hfs] general protection fault in tomoyo_check_acl (3)

On Thu, Mar 14, 2024 at 06:27:31PM +0100, Jan Kara wrote:
> Hi Aleksandr,
> 
> On Thu 14-03-24 17:21:30, Aleksandr Nogikh wrote:
> > Yes, the CONFIG_BLK_DEV_WRITE_MOUNTED=n change did indeed break our C
> > executor code (and therefore our C reproducers). I posted a fix[1]
> > soon afterwards, but the problem is that syzbot will keep on using old
> > reproducers for old bugs. Syzkaller descriptions change over time, so
> > during bisection and patch testing we have to use the exact syzkaller
> > revision that detected the original bug. All older syzkaller revisions
> > now neither find nor reproduce fs bugs on newer Linux kernel revisions
> > with CONFIG_BLK_DEV_WRITE_MOUNTED=n.
> 
> I see, thanks for explanation!
> 
> > If the stream of such bisection results is already bothering you and
> > other fs people, a very quick fix could be to ban this commit from the
> > possible bisection results (it's just a one line change in the syzbot
> > config). Then such bugs would just get gradually obsoleted by syzbot
> > without any noise.
> 
> It isn't bothering me as such but it results in
> CONFIG_BLK_DEV_WRITE_MOUNTED=n breaking all fs-related reproducers and thus
> making it difficult to evaluate whether the reproducer was somehow
> corrupting the fs image or not. Practically it means closing most
> fs-related syzbot bugs and (somewhat needlessly) starting over from scratch
> with search for reproducers. I'm OK with that although it is a bit
> unfortunate... But I'm pretty sure within a few months syzbot will deliver
> a healthy portion of new issues :)

Fwiw, my take on this is that if an active subsystem (responsive to
syzbot bugs and whatnot) is not able to fix a bug within months given a
reproducer then it's likely that the reproducer is not all that useful.

So by closing that issue and we're hopefully getting a better
reproducer.