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

[Sabyrzhan Tasbolatov]

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,
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.

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.

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.

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

Thanks