[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170927145713.GA2847@openwall.com>
Date: Wed, 27 Sep 2017 16:57:13 +0200
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: Linux kernel CVEs not mentioned on oss-security
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.
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?
> And to help combat that, we are doing more and
> more "smart mining"[1] of the kernel commits to try to catch patches
> that match those types of fixes and get them merged into the stable
> kernels.
>
> You can see the initial results of this work with the huge increase in
> patches being merged to the 4.9 and 4.4 stable kernels vs. any older
> stable kernel trees in the past.
>
> thanks,
>
> greg k-h
>
> [1] yes, we know people have been doing this for years, but they almost
> never notify upstream about this for various reasons.
Sounds great.
Thanks,
Alexander
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.
