qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] q800: fix segfault with invalid MacROM


From: Mark Cave-Ayland
Subject: Re: [PATCH] q800: fix segfault with invalid MacROM
Date: Fri, 7 Jan 2022 08:15:03 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1

On 06/01/2022 12:22, Laurent Vivier wrote:

"qemu-system-m68k -M q800 -bios /dev/null" crahses with a segfault
in q800_init().
This happens because the code doesn't check that rom_ptr() returned
a non-NULL pointer .

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/756
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
---
  hw/m68k/q800.c | 8 +++++++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/hw/m68k/q800.c b/hw/m68k/q800.c
index e4c7c9b88ad0..6261716c8f7e 100644
--- a/hw/m68k/q800.c
+++ b/hw/m68k/q800.c
@@ -672,10 +672,16 @@ static void q800_init(MachineState *machine)
/* Remove qtest_enabled() check once firmware files are in the tree */
          if (!qtest_enabled()) {
-            if (bios_size < 0 || bios_size > MACROM_SIZE) {
+            if (bios_size == -1) {
                  error_report("could not load MacROM '%s'", bios_name);
                  exit(1);
              }
+            if (bios_size != MACROM_SIZE) {
+                error_report("Invalid size for MacROM '%s': %d bytes,"
+                             " expected %d bytes", bios_name, bios_size,
+                             MACROM_SIZE);
+                exit(1);
+            }
ptr = rom_ptr(MACROM_ADDR, MACROM_SIZE);
              stl_phys(cs->as, 0, ldl_p(ptr));    /* reset initial SP */

The patch does fix the issue, but it seems a little odd that you can't use -bios path/to/m68k-binary to boot with an arbitrary sized binary which could be useful for reproducers such as https://gitlab.com/qemu-project/qemu/-/issues/360.

How easy would it be to add the extra rom_ptr() NULL check instead?


ATB,

Mark.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]