On 4/9/19 10:08 PM, Peter Maydell wrote: > On Wed, 10 Apr 2019 at 00:40, Markus Armbruster <arm...@redhat.com> wrote: >> >> If the value of get_image_size() exceeds INT_MAX / 2 - 10000, the >> computation of @dt_size overflows to a negative number, which then >> gets converted to a very large size_t for g_malloc0() and >> load_image_size(). In the (fortunately improbable) case g_malloc0() >> succeeds and load_image_size() survives, we'd assign the negative >> number to *sizep. What that would do to the callers I can't say, but >> it's unlikely to be good. >> >> Fix by rejecting images whose size would overflow. >> >> Signed-off-by: Markus Armbruster <arm...@redhat.com> > > I think this patch is missing some attributions for the > security researchers who found the issue initially. > PJP's patch for this from a couple of weeks back has a > reported-by credit: > https://patchew.org/QEMU/20190322073555.20889-1-ppan...@redhat.com/
Oh I missed that thread while on PTO. This answers my "how did you figure that out?" question :) Thanks, Phil.
