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

[Michael Tokarev <mjt () tls msk ru>]

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 () inetric 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