On Tue, 9 Apr 2019 at 21:15, Alistair Francis <alistai...@gmail.com> wrote: > > On Tue, Apr 9, 2019 at 1:08 PM Peter Maydell <peter.mayd...@linaro.org> 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/ > > It seems like from that discussion that this patch is the correct approach. > > I can add the attributions and send a PR for 4.0. I'll send it by EOD > unless anyone has any objections.
Thanks. I think given it's 21:30 here I'm going to postpone tagging rc3 til tomorrow (mid-afternoon UK time). I'm still hoping we can avoid an rc4... thanks -- PMM
