elf_ops: Don't try to g_mapped_file_unref(NULL)
commita1ecb4381829d7eb302bc2d9cb69842c2585601d
authorPeter Maydell <peter.maydell@linaro.org>
Thu, 23 Apr 2020 20:20:11 +0000 (23 21:20 +0100)
committerLaurent Vivier <laurent@vivier.eu>
Mon, 4 May 2020 12:35:23 +0000 (4 14:35 +0200)
tree1bd836dfe15bdd57cdd1999b2284ef670fbf5fd1
parent12d814e901a21fbecc7d34765c02813f187aecef
elf_ops: Don't try to g_mapped_file_unref(NULL)

Calling g_mapped_file_unref() on a NULL pointer is not valid, and
glib will assert if you try it.

$ qemu-system-arm -M virt -display none -device loader,file=/tmp/bad.elf
qemu-system-arm: -device loader,file=/tmp/bad.elf: GLib: g_mapped_file_unref: assertion 'file != NULL' failed

(One way to produce an ELF file that fails like this is to copy just
the first 16 bytes of a valid ELF file; this is sufficient to fool
the code in load_elf_ram_sym() into thinking it's an ELF file and
calling load_elf32() or load_elf64().)

The failure-exit path in load_elf can be reached from various points
in execution, and for some of those we haven't yet called
g_mapped_file_new_from_fd().  Add a condition to the unref call so we
only call it if we successfully created the GMappedFile to start with.

This will fix the assertion; for the specific case of the generic
loader it will then fall back from "guess this is an ELF file" to
"maybe it's a uImage or a hex file" and eventually to "just load as
a raw data file".

Reported-by: Randy Yates <yates@ieee.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Message-Id: <20200423202011.32686-1-peter.maydell@linaro.org>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
include/hw/elf_ops.h