mailing list archives
Re: CVE request - Linux kernel: VFAT slab-based buffer overflow
From: Kurt Seifried <kseifried () redhat com>
Date: Tue, 26 Feb 2013 13:31:59 -0700
-----BEGIN PGP SIGNED MESSAGE-----
On 02/26/2013 11:16 AM, Greg KH wrote:
On Tue, Feb 26, 2013 at 11:56:02AM -0600, Joshua J. Drake wrote:
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
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
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
-----END PGP SIGNATURE-----