Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 27 Feb 2013 18:46:51 -0700
From: Kurt Seifried <>
CC: "Jason A. Donenfeld" <>
Subject: Re: CVE request - Linux kernel: VFAT slab-based buffer

Hash: SHA1

On 02/27/2013 04:24 PM, Jason A. Donenfeld wrote:
> On Thu, Feb 28, 2013 at 12:07 AM, Greg KH <> wrote:
>> Really?  Ok then, please go ahead and try doing this yourself if
>> you feel it is so "obvious" to do.
> I did yesterday, actually. I saw some commit that said "use after 
> free!", saw that it was triggerable by an unpriv'd user, and sent
> it into the list. Kurt took a look at it, agreed with the
> assessment, and assigned a CVE. The commit itself said "use after
> free" -- I didn't even have to do any heavy lifting or
> hair-splitting investigation.

No I didn't. This is why I require good quality requests, anything
else is a waste of my time. If it doesn't meet an easy "definitely a
security bug" I push it back to people and keep poking them with
annoying questions, in some cases this takes weeks or months to be
resolved (some are quite subtle, like that IPv6 Kernel stuff).

I assigned 1600-2000 CVEs last year, it will be more this year. At one
hour per CVE that would be a full years work right there. Even at 1-5
minutes per CVE it's still a huge time sink. The Kernel people are
working with roughly an order or two magnitude more bug reports to
assess (because even trivial looking things can turn out to have nasty
consequences or even represent entirely new classes of flaws, just
look at the recent Ruby stuff or XML stuff).

>> Nope, we are dumb, we do uninteresting, boring work, dealing with
>> broken hardware and demanding users every day.  If we were
>> smarter, we wouldn't be doing this type of thing.
> Come on...

This also goes for security people. If we had any sense we'd go live
in the woods in a cabin and drink moonshine and go hunting. I'm still
assigning CVE's for /tmp file vulns. That's just inexcusably stupid.

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

Version: GnuPG v1.4.13 (GNU/Linux)


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.