linux-kernel - Re: Bug: INFO_ task hung in lock_two

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250124182817.GB3847740@mit.edu>
Date: Fri, 24 Jan 2025 13:28:17 -0500
From: "Theodore Ts'o" <tytso@....edu>
To: Kun Hu <huk23@...udan.edu.cn>
Cc: Kent Overstreet <kent.overstreet@...ux.dev>,
        Dmitry Vyukov <dvyukov@...gle.com>, Jan Kara <jack@...e.cz>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-bcachefs@...r.kernel.org, syzkaller@...glegroups.com
Subject: Re: Bug: INFO_ task hung in lock_two_nondirectories

On Fri, Jan 24, 2025 at 08:22:57PM +0800, Kun Hu wrote:
> 
> But an interesting interaction relationship is that for researchers
> from academia to prove the advanced technology of their fuzzer, they
> seem to need to use their personal finding of real-world bugs as an
> important experimental metric. I think that's why you get reports
> that are modeled after syzbot (the official description of syzkaller
> describes the process for independent reports). If the quality of
> the individual reports is low, it does affect the judgment of the
> maintainer, but also it is also a waste of everyone's time.

If you're going to do this, I would suggest that you make sure that
you're actually finding new bugs.  More often than not, after wasting
a huge amount of time of upstream developers because the researchers
don't set up the syzbot dashboard and e-mail service to test to see if
a patch fixes a bug (often which we can't reproduce on our own because
it's highly environment sensitive), we discover that it's already been
reported on the upstream syzbot.

Which makes the academic syzbot a *double* waste of time, and this
trains upstream developers to simply ignore reports from these
research forks of syzbot unless it comes with a reproducer, or maybe
(this hasn't happened yet) if the researchers actually set up the web
dashboard and e-mail responder.

I also blame the peer reviewers for the journals, for not asking the
question, "why haven't you shown that the 'real world' bugs that your
forked syzbot has found are ones that the original syzcaller hasn't
found yet?"  And for not demanding of the academics, "if you want
*real* impact, get your changes merged upstream with the upstream
syzcaller, so that it will continue to find and fix vulnerabilities
instead of ceasing the moment we accept your paper."

Cheers,

						- Ted