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

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

[Sabyrzhan Tasbolatov]

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

Please also see the diagram in the PR
docs/linux/reporting_kernel_bugs.png.

Thanks

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

[Greg KH]

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.

Just reference the in-kernel documentation about security bugs and cves
for this information, that is up to date properly.  If you wish to write
additional documentation for external projects, that's up to those
projects.

good luck!

greg k-h

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

[Greg KH]

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!)  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

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

[Sabyrzhan Tasbolatov]

On Mon, Nov 11, 2024 at 7:42 PM Greg KH <gregkh@linuxfoundation.org> 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@kernel.org
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

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@linuxfoundation.org> 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@kernel.org
> 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