[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 27 Feb 2013 08:15:47 -0800
From: Greg KH <greg@...ah.com>
To: oss-security@...ts.openwall.com
Subject: Re: CVE request - Linux kernel: VFAT slab-based
buffer overflow
On Wed, Feb 27, 2013 at 07:08:58PM +0400, Solar Designer wrote:
> On Wed, Feb 27, 2013 at 06:48:34AM -0800, Greg KH wrote:
> > On Wed, Feb 27, 2013 at 07:31:30AM +0100, Petr Matousek wrote:
> > > For starters, security@...nel.org submissions should be posted to
> > > oss-security or any other security related public mailing list when the
> > > patch is being committed.
> >
> > That's not going to happen, and you know that, to do so would be totally
> > irresponsible of us and directly harm your users.
>
> Huh?! Maybe you misread what Petr wrote? Note: "when the patch is
> being committed". At this point, the security issue is public, and it
> just needs to be properly communicated to all those interested
> (including distros, sysadmins, etc.), such as via oss-security. Not
> doing this favors those few who spend time to review commits on their
> own; some of them do it for purposes other than informing the public.
We (the kernel team) well know this, and have been over this topic
numerous times in the past. We have come to the conclusion that it is
not good for us to be publicly stating "here look, here's how you
exploit the kernel!" at the exact moment we commit the patch to the
public tree because suddenly you now have shown how all systems in the
world are exploitable, with no chance for anyone to have protected their
systems ahead of time.
Instead, we have no problem with groups like vendor-sec being notified
of these issues, and allowing them to push out updates, before _they_
notify the world of the problem. And, for a long time, I thought
vendor-sec was being notified of all of the issues that
security@...nel.org knew about, if this has suddenly changed, please let
me know and I will be glad to resolve it.
Yes, this does seem to favor those who pay closer attention to the
commits going into the tree than those who do not, but we do this to try
to balance the needs of the larger majority of users.
It's a tough problem, full of grey areas, like the real world requires,
and I personally wrestle with it all the time. At the moment, I feel
this is the best that we have come up with, and I know that others
strongly disagree, which is fine, debate about stuff like this is good
to have.
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.
