[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 26 Feb 2013 21:03:46 -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 Tue, Feb 26, 2013 at 11:41:53PM -0500, Michael Gilbert wrote:
> On Tue, Feb 26, 2013 at 6:05 PM, Jason A. Donenfeld wrote:
> > On Tue, Feb 26, 2013 at 10:05 PM, Kurt Seifried
> >> The problem with security is you have to basically do it 100%
> >> correctly 100% of the time, otherwise things fall through the cracks
> >> (like this VFAT thing).
> >
> > Also, what about the tmpfs one from yesterday? Nobody involved in the
> > patch reported that as a security bug to this list, until I saw it
> > myself, just by chance, as a random person on the internet, and posted
> > it to the list. In that case, it was clearly marked "use-after-free",
> > but nobody involved requested a CVE.
>
> I actually see Greg KH's recent interest in oss-sec as a positive
> sign.
Recent? I've been involved in oss-sec from the very start of it, and
before that, I was on vendor-sec since 2000 or so.
> Anyway, on a more serious note, at some point, acceptance will look
> something like a real kernel-sec team that does essentially what you
> just did, but on a continual basis: reviewing most/all commits for
> potential security concerns and forwarding them to oss-sec to increase
> identification and awareness to be applied downstream.
I will say flat out that this is an impossible task to accomplish.
As proof of that, I suggest you do this for just one major kernel
release cycle (2-3 months long).
You do know the number of patches applied to the Linux kernel every
hour, right?
Would you have caught the patch that started this thread? I sure
didn't, and I was the one who originally applied it to the kernel tree
in the first place. Doing "root-cause" research for every patch is
non-trivial, as I know you realize.
> Unfortunately a person/group needs to want to scratch that particular
> itch, and more importantly be able to deal with leaders antipathetic
> to their work.
I'm not apathetic at all, you are underestimating the ability for
something like this to be even possible.
> Also, as Kurt was alluding to, the rewards don't seem to be there, and
> of course there is a lot of potential for pain (i.e. dealing with the
> anger).
What anger? I push out on average, 100 kernel bugfixes a week publicly
for all to see, for multiple kernel versions. Trying to do the
categorization you wish for above for just that small number of patches
is impossible to do, ask the people who have tried to do it.
I would be very happy to see just these bugfixes to be categorized, and
if people wish to dig further into the patches I miss, I would be more
than willing to take them into the stable kernel releases as well.
I gladly welcome any help in this area, and always 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.
