[Ksummit-discuss] [MAINTAINERS SUMMIT] CVE patches annotation

[Greg KH]

On Tue, Sep 11, 2018 at 02:00:58PM +0200, Takashi Iwai wrote:
> On Tue, 11 Sep 2018 13:57:09 +0200,
> Justin Forbes wrote:
> > 
> > On Mon, Sep 10, 2018 at 8:11 PM, Eduardo Valentin <edubezval at gmail.com> wrote:
> > > Hello,
> > >
> > > I would like to open a discussion on improving the annotation
> > > around CVE patches on the Linux kernel. Today, the kernel Documentation
> > > mentions about CVE assignment and asks as a good practice to at least
> > > mention the CVE  number in the patch [1]. But, is that enough?
> > > Should the kernel have more info about what patches fixes a specific
> > > CVE?
> > >
> > > Some of the challenges with current process:
> > > - The info about of about what CVEs have been patched in a kernel is
> > >   outside the kernel tree / git history.
> > > - Today, some patches have the CVE info, and many others do not mention
> > >   anything about CVE number.
> > > - As mentioned in the kernel documentation [1], not always the CVE
> > >   number is assigned when the patch(es) go into the kernel tree, so
> > >   maybe this may require some post merge annotation?
> > 
> > This is also sometimes relevant when you can fix and embargoed CVE
> > before embargo lifts because the actual fix doesn't make it obvious
> > that there is a security issue. Obfuscation is a somewhat useful tool
> > when fixing security bugs sometimes.  I would rather get the patches
> > in sooner than have them be properly annotated for the security fixes
> > they really are.
> 
> I hoped that git-notes could be used for such additional post-release
> notes.  But it seems that it never flies well due to various
> reasons...

I do remember a tree somewhere on github that had a tracking between
cves and kernel commits.  It was a pain to keep up to date, but the
author was doing a good job for a number of months.

Can't find it now...

Anyway, the main problem here is that almost all the time, CVEs are
assigned _after_ the patch is in the kernel tree.  And we can't go back
in time to change a changelog entry.

Also, what about huge series of patches all to fix one CVE?  What would
you put down for the single Meltdown commit?

So this is up to those that wish to track these types of things, good
luck!

And yes, this is my "CVEs are a joke" feelings coming through here,
sorry if you are someone who has to treat them as something important...

greg k-h