oss-security - Re: CVE request: qemu e1000 emulated device gues-side buffer overflow

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <50DEE7A1.3060405@msgid.tls.msk.ru>
Date: Sat, 29 Dec 2012 16:52:49 +0400
From: Michael Tokarev <mjt@....msk.ru>
To: oss-security@...ts.openwall.com
Subject: Re: CVE request: qemu e1000 emulated device gues-side
 buffer overflow

I'm not sure what's going on, but no one replied to this email.

Meanwhile, this very place received one more bugfix -- see

http://lists.nongnu.org/archive/html/qemu-devel/2012-12/msg00533.html

Is this an issue serious enough to get a CVE#?

Thanks,

/mjt

19.12.2012 23:52, Michael Tokarev wrote:
> qemu-1.3 includes the following patch by Michael Contreras:
>
>   http://thread.gmane.org/gmane.comp.emulators.qemu/182666
>    (initial submission)
>   http://git.qemu.org/?p=qemu.git;a=commitdiff;h=b0d9ffcd0251161c7c92f94804dcf599dfa3edeb
>    (the commit)
>
>
> commit b0d9ffcd0251161c7c92f94804dcf599dfa3edeb
> Author: Michael Contreras <michael@...tric.com>
> 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> inetric.com>
>   ---
>
>   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 --
>
>   http://thread.gmane.org/gmane.comp.emulators.qemu/183137
>
> 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
>

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.