Peter Maydell <peter.mayd...@linaro.org> writes: > 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/
Uh, I missed that thread. Thanks for doing my homework for me! >> 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... Want me to look for a few more integer overflows today? ;-P