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. Alistair > > thanks > -- PMM >
