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" 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 > >  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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ