[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170928143313.GA6123@kroah.com>
Date: Thu, 28 Sep 2017 16:33:13 +0200
From: Greg KH <greg@...ah.com>
To: oss-security@...ts.openwall.com
Subject: Re: Linux kernel CVEs not mentioned on oss-security
On Wed, Sep 27, 2017 at 04:57:13PM +0200, Solar Designer wrote:
> On Wed, Sep 27, 2017 at 03:04:24PM +0200, Greg KH wrote:
> > I've not ever really run into any "known security
> > fix" not being cc:ed to stable. Do you have any known examples where I
> > can go poke the maintainers to do better?
>
> I haven't been keeping track, but as you're aware Brad Spengler brought
> these up from time to time, including recently on this list:
>
> http://www.openwall.com/lists/oss-security/2017/08/05/1
>
> > We have plenty of the normal "bugfix was merged that a few years later
> > turned out to be a 'security' issue, but no one realized it at the time"
> > changes that get merged.
>
> It feels unlikely Al Viro didn't realize the commit on 2017-07-07 was a
> security fix, given the description of the race condition and the kernel
> panic triggerable by an unprivileged user posted to linux-fsdevel on
> 2017-05-31, and the Red Hat private Bug created on 2017-07-06. Rather,
> it could have been intended to give distros some time to patch (4 weeks
> to Red Hat, 1 week to the rest?) before drawing even more attention to
> the problem. But this also resulted in stable not CC'ed on the commit.
>
> I am not blaming anyone - it's a tough tradeoff. For an already public
> issue (since 2017-05-31 on linux-fsdevel), the committed fix doesn't
> literally leak it (can't leak what's already public), although it does
> create some additional exposure (minimized by not mentioning security
> relevance and not CC'ing stable). I am also not blaming Red Hat for
> giving linux-distros less time - that's possibly caused by linux-distros
> policy of 14 days max, 7 days preferred. I think the 7 or 8 days was
> just right. I think Red Hat should learn to handle such issues much
> quicker, though, so that up to 14 days would be comfortable for their
> own handling as well. Especially for semi-public issues (in this case
> technically public, but obscure).
>
> I am primarily saying that we should admit that such cases exist, I
> suppose for varying reasons, when stable is not CC'ed on what's known to
> be a security issue at time of commit.
Yes, fair enough, you are right. Those cases do exist, this one fell
through the cracks, which will always happen, we are all human, even Al :)
> I don't know if you should "go poke" Al Viro "to do better". While many
> would disagree with resolving the tradeoff like that, some would support
> that. As an option, you could acknowledge that such cases will come up
> from time to time, and ask to be notified of them by means other than
> CC'ing stable. Maybe this was already in place for that one occasion?
I don't have access to my email archives at the moment, but I _think_
this one was my fault as it was on my list of things "go look at", and I
never go to it in time. My current list of patches that fall into that
category is rather large, due to my recent travels, hopefully I'll catch
up on that by the end of this month.
I always suggest that if I do miss things, please let me know through
whatever way you want to (public list, security@k.o, private email,
poking me on irc, taking me out to drinks, etc.)
thanks,
greg k-h
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
