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: <5BCDEDB6-7A92-4401-A0A8-A12EF2F27ED0@m.fudan.edu.cn>
Date: Thu, 16 Jan 2025 17:37:24 +0800
From: Kun Hu <huk23@...udan.edu.cn>
To: Kent Overstreet <kent.overstreet@...ux.dev>
Cc: 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

> 
> Makes sense. Sorry if I came off a bit strong, there's been a couple
> syzbot copycats and I find I keep repeating myself :)
> 
> So, it sounds like you're getting nudged to work upstream, i.e. people
> funding you want you to be a bit better engineers so the work you're
> doing is taken up (academics tend to be lousy engineers, and vice
> versa, heh).
> 
> But if you're working on fuzzing, upstream is syzbot, not the kernel -
> if there's a community you should be working with, that's the one.
> 
> An individual bug report like this is pretty low value to me. I see a
> ton of dups, and dups coming from yet another system is downright
> painful.
> 
> The real value is all the infrastructure /around/ running tests and
> finding bugs: ingesting all that data into dashboards so I can look for
> patterns, and additional tooling (like the ktest/syzbot integration, as
> well as other things) for getting the most out of every bug report
> possible.
> 
> If you're working on fuzzing, you don't want to be taking all that on
> solo. That's the power of working with a community :) And more than
> that, we do _very_ much need more community minded people getting
> involved with testing in general, not just fuzzing.
> 

Hi Kent,

Thank you for your insights.

I have a couple of questions I would like to ask for your advice on:

From a testing perspective, we have modified syzkaller and discovered some issues. It’s true that researchers working on fuzzing often lack a deep understanding of the kernel, making it difficult to precisely determine the scope of reported problems. Meanwhile, syzbot provides a description of the reporting process (please refer to the link below) and encourages researchers to report bugs to maintainers. However, there seems to be a significant gap here—researchers may end up reporting bugs to the wrong maintainers or submitting reports that lack value. This seems like a serious issue. Could the kernel community consider establishing a standardized process to reduce wasted time on all sides and prevent researchers from inflating bug counts just to validate their papers?

Link: https://github.com/google/syzkaller/blob/master/docs/linux/reporting_kernel_bugs.md

It is often suggested that researchers collaborate with syzbot. What should such collaboration look like in terms of form and content? From a maintainer's perspective, how would you prefer to see researchers who report bugs work with syzbot? Since I’m new to this field, I’m not very familiar with the process and would greatly appreciate your guidance.