Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 29 Dec 2012 20:23:38 -0700
From: Kurt Seifried <>
CC: Michael Tokarev <>,
Subject: Re: CVE request: qemu e1000 emulated device gues-side
 buffer overflow

Hash: SHA1

On 12/29/2012 05:52 AM, Michael Tokarev wrote:
> I'm not sure what's going on, but no one replied to this email.

I was waiting for someone to reply/post more info, didn't happen until
now =).

> Meanwhile, this very place received one more bugfix -- see
>  Is this an issue serious enough to get a CVE#?

I am merging these issues into a single CVE, same researcher, same
version of Linux kernel, basically same problem. If anyone objects
strongly however I can split (assumption being the CVE assigned now
would be for the Dec 3 2012 issue). So we have:

Dec 3 2012:;a=commitdiff;h=b0d9ffcd0251161c7c92f94804dcf599dfa3edeb

+/* this is the size past which hardware will drop packets when
setting LPE=0 */
+    /* Discard oversized packets if !LPE and !SBP. */

Dec 5 2012:

+/* this is the size past which hardware will drop packets when
setting LPE=1 */


Please use CVE-2012-6075 for these issues.

> Thanks,
> /mjt
> 19.12.2012 23:52, Michael Tokarev wrote:
>> qemu-1.3 includes the following patch by Michael Contreras:
>> (initial
>> submission)
(the commit)
>> commit b0d9ffcd0251161c7c92f94804dcf599dfa3edeb Author: Michael
>> Contreras <> Date:   Sun Dec 2 20:11:22 2012
>> -0800 Subject: e1000: Discard packets that are too long if !SBP
>> and !LPE
>> The e1000_receive function for the e1000 needs to discard
>> packets longer than 1522 bytes if the SBP and LPE flags are
>> disabled. The linux driver assumes this behavior and allocates
>> memory based on this assumption.
>> Signed-off-by: Michael Contreras <michael <at>> ---
>> Tested with linux guest. This error can potentially be exploited.
>> At the very least it can cause a DoS to a guest system, and in
>> the worse case it could allow remote code execution on the guest
>> system with kernel level privilege. Risk seems low, as the
>> network would need to be configured to allow large packets.
>> The last comment, which didn't went into the commit message,
>> indicates that it is possible to send larger packet to a guest
>> and cause a buffer overflow with usual outcome in such cases.
>> Yes indeed, the impact is rather low, because the network should
>> be configured to allow larger packets to reach the guest, which
>> is not usually the case -- either the host network is configure
>> for MTU=1500 and disallow large packets entirely, or BOTH host
>> and guest network is configured to allow large packets.  In other
>> words, either all devices on the network are configred to accept
>> jumbo frames, no no jumbo frames are enabled at all.
>> That's why I'm not sure whenever this can be considered a
>> vulnerability which deserves a CVE# or not, so I'm asking here.
>> There's another followup bugfix in the same area, now talking
>> about "extra-large" frames --
>> If this issue deserves a CVE#, I guess both patches can be seen
>> as a single bugfix.
>> This impacts qemu and all products based on it and using e1000
>> emulated device, including qemu-kvm, xen and others.
>> Thanks,
>> /mjt

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

Version: GnuPG v1.4.12 (GNU/Linux)


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ