Re: [RFC] syzkaller/docs: reporting kernel security bugs guide

[Greg KH]

On Mon, Nov 11, 2024 at 08:36:01PM +0500, Sabyrzhan Tasbolatov wrote:
> On Mon, Nov 11, 2024 at 7:42 PM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Mon, Nov 11, 2024 at 03:37:27PM +0100, Greg KH wrote:
> > > On Mon, Nov 11, 2024 at 06:24:36PM +0500, Sabyrzhan Tasbolatov wrote:
> > > > Hello,
> > > >
> > > > Greg,
> > > > Could you please confirm that the updated version of
> > > > reporting Linux kernel security bugs guide is correct
> > > > since kernel.org is CNA as of February 13, 2024 and
> > > > with linux-cve-announce reference?
> > > >
> > > > The updated doc and drawn diagram is available
> > > > in this PR of syzkaller project:
> > > > https://github.com/google/syzkaller/pull/5461
> > >
> > > I can't read this mess:
> > >       https://github.com/google/syzkaller/pull/5461/commits/35b45ef3c4600fd62f5d05a17fc6855fc0b5e402
> > >
> > > So I have no idea, sorry.
> >
> > Ah, the graph is at the bottom of the page, kind of messy...
> >
> > Anyway, as I have stated numerous times, I DO NOT RECOMMEND EVER
> > CONTACTING the linux-distros mailing list for lots of various reasons.
> > You do so at your own risk and liability (i.e. doing so imparts a number
> > of requirements on you!)
> 
> Thanks for the feedback! Sorry for the messy diagram :(
> I don't have the real experience with kernel CVEs or contacting linux-distros,
> so this updated syzkaller documentation reflects only my understanding
> based on reading guides from kernel.org and oss-security,
> and also watching your recent OS Summit talk in Japan.
> 
> So I've wanted to update this guide for myself in the first place :)
> 
> > So be VERY VERY VERY careful to ever tell
> > anyone to do so as the side affects can be very bad in some cases (i.e.
> > they "blackmail" you to release information even if you don't have a
> > fix.)
> >
> > good luck!
> >
> > greg k-h
> 
> >From oss-security documentation [1] it's said:
> [1] https://oss-security.openwall.org/wiki/mailing-lists/distros
> 
> > For Linux kernel issues, you must notify the kernel security team first, wait for the fix,
> > and only then notify linux-distros or oss-security (depending on whether the information
> > is still private or already public, as well as on issue severity).
> 
> I understand that their policy follows with security@xxxxxxxxxx
> interests to release the fix,

No it does not at all.  Not even close.  Don't be confused, it's totally
different and again, something I consider as blackmail.

> but it may be postponed if the reporter asks for an embargo period to
> let linux-distros prepare the update rollout during this embargo
> period and prior to the bug disclosure, the fix should be merged into
> the Linux kernel stable tree first.

Again, no, security@k.o does not work with linux-distros at all, we have
different rules and timelines that do not work together.

Only after security@k.o has fixed something then could someone possibly
contact linux-distros if they really want to.  But that's on them, and
again, keep the two workflows totally separate.

Also realize that linux-distros is not needed to get fixes out to the
distros for the kernel, they should be taking the normal stream of fixes
we provide in the stable releases at a weekly basis.

> If the reporter chooses not to request for an embargo period for
> linux-distros sake, then the fix is merged ASAP, CVE is assigned
> "after-the-fact" and the reporter may optionally report to
> oss-security, and linux-distros can pick the merged fix post factum.
> Personally, I prefer this option without the embargo period
> complexity.

Again, no, keep the two groups separate, they do not work combined in
any way.

CVEs are also totally separate from all of this, it's not an issue that
you probably even need to add here at all as why are they needed here?

> But this is according to my non-experienced understanding, so there
> are definitely pitfalls
> I am not aware of.
> 
> So I'm still confused how the syzkaller doc should be updated,
> perhaps it should just refer to existing kernel.org and oss-security guidelines,
> so the reporter should consider which option is preferable.

Again, they are separate, just point at our existing documentation for
kernel.org, as we always keep that up to date.  Why even point at
oss-security, as that's not something that normally is used for kernel
issues otherwise it would just be a constant stream of patches sent
there (i.e. our normal mailing lists.)

> Andrey, please suggest as well or let me know
> how to proceed with the syzkaller doc update.

Just point at our existing documentation please.  That should be all
that is needed.

thanks,

greg k-h