On 09/05/14 11:33, Gerd Hoffmann wrote:
> On Fr, 2014-09-05 at 11:06 +0200, Laszlo Ersek wrote:
>>> > > Makes sense. I think it is easier to just multiply in 64bit, then
>> > check
>>> > > the result is small enougth (new patch attached).
>> >
On 09/05/14 10:58, Gerd Hoffmann wrote:
> Hi,
>
>> I can't track this back far enough. I'd feel safer if you checked that
>> the multiplication can't overflow even in uint64_t.
>
> Effectively it comes from the emulated graphics hardware (anything in
> hw/display/*). The gfx emulation must mak
ore the guest has a chance to do something
> evil.
>
> Fix that by switching to dynamic allocation for the buffer.
>
> CVE-2014-3615
>
> Cc: qemu-sta...@nongnu.org
> Cc: secal...@redhat.com
> Cc: Laszlo Ersek
> Signed-off-by: Gerd Hoffmann
> ---
> ui/spice-di
havior, when modenr is out of range.
In practice, meh -- the check is done early enough to prevent
dereferencing the (already undefined) pointer.
I also guess gcc is *not* smart enough to derive the undefined-ness as
soon as we do the wrong initialization. (Because if it were smart en
RGB_BYTES_PER_PIXEL array by one element, but it missed to append a zero
to IS_IMAGE_TYPE_PLT, and a one to IS_IMAGE_TYPE_RGB. Do so now.
Related RHBZ: 928973.
Signed-off-by: Laszlo Ersek
---
common/lz_common.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/common
