Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 26 Feb 2013 13:31:59 -0700
From: Kurt Seifried <>
CC: Greg KH <>
Subject: Re: CVE request - Linux kernel: VFAT slab-based buffer

Hash: SHA1

On 02/26/2013 11:16 AM, Greg KH wrote:
> On Tue, Feb 26, 2013 at 11:56:02AM -0600, Joshua J. Drake wrote:
>> All,
>> I'd like to request a CVE for an issue leading to a buffer
>> overflow of a slab allocated buffer in the VFAT file system code.
>> The issue manifests when converting UTF8 characters to UTF16
>> inside the "utf8s_to_utf16s" function. Reaching this code
>> requires writing to a VFAT partition that has been mounted with
>> the "utf8" option. Ubuntu 10.04 mounts USB sticks with this
>> option by default. Most Android devices mount eMMC/SD cards/etc
>> with this option.
>> The issue affects kernels prior to 3.2. Many Android devices
>> remain affected today.
>> I'm not entirely sure when the issue was introduced at this
>> moment. It appears to have been introduced here: 
The issue was fixed here:
The issue was partially disclosed here (this spurred my investigation):
>> Props to G13 for finding it. It's pretty disappointing that 
>> Google/Android security teams (and of course Linux maintainers)
>> didn't responsibly disclose the issue so other Linux kernel
>> packagers could package a fix.

Please use CVE-2013-1773 for this issue.

> Ok, how could the Linux maintainers have done anything about this,
> when the developers involved in creating this patch didn't even
> realize it was a "security" issue in the first place?
> I'm tired of people complaining about how the Linux kernel
> developers handle security issues, when no one seems to have a
> suggestion as to how anything could actually be done better.
> And note, I was one of the people involved in this patch, and I
> didn't notice anything special about it, so if you want to blame
> anyone, blame me for not tagging it for inclusion in the stable
> kernel releases.
> greg k-h

I suspect part of the problem is scale. Most people don't understand
the scale at which the Linux Kernel and vendors handle bug fixes and
code changes. External people simply see a few poorly handled security
related issues and probably think "well how hard can it be to properly
a few extra security flaws?" but they don't see that those 5 security
issues were buried in 10,000 other code fixes. The resources needed to
audit every code change for a security impact simply aren't available
(and even if we had enough talented people who exactly is going to pay
them all?).

While things are not perfect (and likely never will be) I think they
are pretty good overall considering how much code and code change the
Linux Kernel handles.

- -- 
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.