[Ksummit-2013-discuss] Topic Proposal: Handling Security Issues in the kernel

Kees Cook keescook at chromium.org
Tue Aug 13 18:07:28 UTC 2013


On Tue, Aug 13, 2013 at 11:02 AM, Ben Hutchings <ben at decadent.org.uk> wrote:
> On Tue, 2013-08-13 at 10:39 -0700, Greg KH wrote:
>> On Tue, Aug 13, 2013 at 09:37:29AM -0700, Andy Lutomirski wrote:
> [...]
>> > I'd propose a (quasi-)official list of known kernel vulnerabilities.
>> > It could live in its own git tree (one text file per known
>> > vulnerability, named by CVE number?), with private branches for
>> > vulnerabilities that shouldn't be published yet.
>>
>> People have proposed this in the past, tagging things like this, but I
>> don't think it ever lasted more than a kernel release or two.  But
>> please try to do it if you can.
>>
>> > (I could even be convinced to maintain such a thing for a while, but I
>> > don't currently have access to any non-public vulnerability
>> > information.)
>>
>> I'd recommend working with the linux-distros@ people if you want
>> something like this, that's the best place for coordinating it.
>
> Debian's security team has been doing this for some years now:
>
> https://security-tracker.debian.org/tracker/source-package/linux
> http://anonscm.debian.org/viewvc/kernel-sec/
>
> I don't make any promises about how complete or accurate this
> information is.  And only the stable kernel branches used by Debian are
> currently tracked there.  But there may be some possibility of sharing
> information and pooling work.

Yeah, Ubuntu does similar. There is a "introduced by" and "fixed by"
SHA tracking. See the "Patches" section:

http://people.canonical.com/~ubuntu-security/cve/2013/CVE-2013-1763.html

-Kees

-- 
Kees Cook
Chrome OS Security


More information about the Ksummit-2013-discuss mailing list