On Thu, Aug 27, 2020 at 02:11:23PM +0200, Greg Kroah-Hartman wrote: > On Thu, Aug 27, 2020 at 12:53:19PM +0200, Krzysztof Kozlowski wrote: > > --- a/Documentation/admin-guide/security-bugs.rst > > +++ b/Documentation/admin-guide/security-bugs.rst > > @@ -78,6 +78,12 @@ include linux-distros from the start. In this case, remember to prefix > > the email Subject line with "[vs]" as described in the linux-distros wiki: > > <http://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists> > > > > +Fixes for non-exploitable bugs which do not pose a real security risk, should > > +be disclosed in a regular way of submitting patches to Linux kernel (see > > +:ref:`Documentation/process/submitting-patches.rst <submitting-patches>`). > > +Just because patch fixes some off-by-one or NULL pointer exception, does not > > +classify it as a security bug which should be discussed in closed channels. > > I said this on another thread, but almost always, when we get reports > like this on security@k.o, we do push them back to public lists. > > For the most part, this paragraph is not going to help much (mostly for > the reason that no one seems to read it, but that's a different > topic...) We get crazy reports all the time, and that's fine, because > sometimes, there is a real issue in some of them. And for that, we do > want to be careful. We also have many docuemented "off-by-one" bugs > that were real security issues (there's a blog post somewhere about how > a developer turned such a bug into a root hole, can't find it right > now...) > > So while I understand the temptation here, based on the current > security@k.o traffic, I doubt this will really change much :( And given our relatively low traffic, I'd rather we (the security@xxxxxxxxxx folks) make the determination if things should be public or private. We should be the ones on the hook for those judgement calls, not the reporter reading our documentation. :) -- Kees Cook
