| Message ID | 1536729461-2692-1-git-send-email-liq3ea@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | fw_cfg_mem: add read memory region callback | expand |
Hi On Wed, Sep 12, 2018 at 9:22 AM Li Qiang <liq3ea@gmail.com> wrote: > > The write/read should be paired, this can avoid the > NULL-deref while the guest reads the fw_cfg port. > > Signed-off-by: Li Qiang <liq3ea@gmail.com> Do you have a reproducer and/or a backtrace? memory_region_dispatch_write() checks if ops->write != NULL. > --- > hw/nvram/fw_cfg.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c > index d79a568f54..6de7809f1a 100644 > --- a/hw/nvram/fw_cfg.c > +++ b/hw/nvram/fw_cfg.c > @@ -434,6 +434,11 @@ static bool fw_cfg_data_mem_valid(void *opaque, hwaddr addr, > return addr == 0; > } > > +static uint64_t fw_cfg_ctl_mem_read(void *opaque, hwaddr addr, unsigned size) > +{ > + return 0; > +} > + > static void fw_cfg_ctl_mem_write(void *opaque, hwaddr addr, > uint64_t value, unsigned size) > { > @@ -468,6 +473,7 @@ static bool fw_cfg_comb_valid(void *opaque, hwaddr addr, > } > > static const MemoryRegionOps fw_cfg_ctl_mem_ops = { > + .read = fw_cfg_ctl_mem_read, > .write = fw_cfg_ctl_mem_write, > .endianness = DEVICE_BIG_ENDIAN, > .valid.accepts = fw_cfg_ctl_mem_valid, > -- > 2.11.0 > >
Hi, Marc-André Lureau <marcandre.lureau@gmail.com> 于2018年9月12日周三 下午3:16写道： > Hi > > On Wed, Sep 12, 2018 at 9:22 AM Li Qiang <liq3ea@gmail.com> wrote: > > > > The write/read should be paired, this can avoid the > > NULL-deref while the guest reads the fw_cfg port. > > > > Signed-off-by: Li Qiang <liq3ea@gmail.com> > > Do you have a reproducer and/or a backtrace? > memory_region_dispatch_write() checks if ops->write != NULL. > As far as I can see, the fw_cfg_mem is not used in x86 and used in arm. And from my impression, this will NULL read will be a issue. So I just omit the 'read' field in fw_cfg_comb_mem_ops(this is used for x86) to emulate the issue. When using gdb, I got the following backtrack. Thread 5 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffca15b700 (LWP 7637)] 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in ?? () #1 0x0000555555872492 in memory_region_oldmmio_read_accessor (mr=0x5555567fa870, addr=1, value=0x7fffca158510, size=1, shift=0, mask=255, attrs=...) at /home/liqiang02/qemu-devel/qemu/memory.c:409 #2 0x000055555586f2dd in access_with_adjusted_size (addr=addr@entry=1, value=value@entry=0x7fffca158510, size=size@entry=1, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=0x555555872440 <memory_region_oldmmio_read_accessor>, mr=0x5555567fa870, attrs=...) at /home/liqiang02/qemu-devel/qemu/memory.c:593 #3 0x0000555555873e90 in memory_region_dispatch_read1 (attrs=..., size=1, pval=0x7fffca158510, addr=1, mr=0x5555567fa870) at /home/liqiang02/qemu-devel/qemu/memory.c:1404 #4 memory_region_dispatch_read (mr=mr@entry=0x5555567fa870, addr=1, pval=pval@entry=0x7fffca158510, size=1, attrs=attrs@entry=...) at /home/liqiang02/qemu-devel/qemu/memory.c:1423 #5 0x0000555555821e42 in flatview_read_continue (fv=fv@entry=0x7fffbc03f370, addr=addr@entry=1297, attrs=..., buf=<optimized out>, buf@entry=0x7ffff7fee000 "", len=len@entry=1, addr1=<optimized out>, l=<optimized out>, mr=0x5555567fa870) at /home/liqiang02/qemu-devel/qemu/exec.c:3293 #6 0x0000555555822006 in flatview_read (fv=0x7fffbc03f370, addr=1297, attrs=..., buf=0x7ffff7fee000 "", len=1) at /home/liqiang02/qemu-devel/qemu/exec.c:3331 #7 0x000055555582211f in address_space_read_full (as=<optimized out>, addr=addr@entry=1297, attrs=..., buf=buf@entry=0x7ffff7fee000 "", len=len@entry=1) at /home/liqiang02/qemu-devel/qemu/exec.c:3344 #8 0x000055555582225a in address_space_rw (as=<optimized out>, addr=addr@entry=1297, attrs=..., attrs@entry=..., buf=buf@entry=0x7ffff7fee000 "", len=len@entry=1, is_write=is_write@entry=false) at /home/liqiang02/qemu-devel/qemu/exec.c:3374 #9 0x0000555555886239 in kvm_handle_io (count=1, size=1, direction=<optimized out>, data=<optimized out>, attrs=..., port=1297) at /home/liqiang02/qemu-devel/qemu/accel/kvm/kvm-all.c:1731 #10 kvm_cpu_exec (cpu=cpu@entry=0x5555566e9990) at /home/liqiang02/qemu-devel/qemu/accel/kvm/kvm-all.c:1971 #11 0x000055555585d3de in qemu_kvm_cpu_thread_fn (arg=0x5555566e9990) at /home/liqiang02/qemu-devel/qemu/cpus.c:1257 #12 0x00007fffdbd58494 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #13 0x00007fffdba9aacf in clone () from /lib/x86_64-linux-gnu/libc.so.6 So I send out this path. But this time when I not use gdb, there is no segmentation. So this may not a issue. If who has a arm environment, he can try this, the PoC is just easy. just read the 0x510 port with word. Thanks, Li Qiang > > > --- > > hw/nvram/fw_cfg.c | 6 ++++++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c > > index d79a568f54..6de7809f1a 100644 > > --- a/hw/nvram/fw_cfg.c > > +++ b/hw/nvram/fw_cfg.c > > @@ -434,6 +434,11 @@ static bool fw_cfg_data_mem_valid(void *opaque, > hwaddr addr, > > return addr == 0; > > } > > > > +static uint64_t fw_cfg_ctl_mem_read(void *opaque, hwaddr addr, unsigned > size) > > +{ > > + return 0; > > +} > > + > > static void fw_cfg_ctl_mem_write(void *opaque, hwaddr addr, > > uint64_t value, unsigned size) > > { > > @@ -468,6 +473,7 @@ static bool fw_cfg_comb_valid(void *opaque, hwaddr > addr, > > } > > > > static const MemoryRegionOps fw_cfg_ctl_mem_ops = { > > + .read = fw_cfg_ctl_mem_read, > > .write = fw_cfg_ctl_mem_write, > > .endianness = DEVICE_BIG_ENDIAN, > > .valid.accepts = fw_cfg_ctl_mem_valid, > > -- > > 2.11.0 > > > > > > > -- > Marc-André Lureau >
On 09/12/18 10:02, Li Qiang wrote: > Hi, > > Marc-André Lureau <marcandre.lureau@gmail.com> 于2018年9月12日周三 下午3:16写道： > >> Hi >> >> On Wed, Sep 12, 2018 at 9:22 AM Li Qiang <liq3ea@gmail.com> wrote: >>> >>> The write/read should be paired, this can avoid the >>> NULL-deref while the guest reads the fw_cfg port. >>> >>> Signed-off-by: Li Qiang <liq3ea@gmail.com> >> >> Do you have a reproducer and/or a backtrace? >> memory_region_dispatch_write() checks if ops->write != NULL. >> > > As far as I can see, the fw_cfg_mem is not used in x86 and used in arm. > And from my impression, this will NULL read will be a issue. So I just > omit the 'read' field in fw_cfg_comb_mem_ops(this is used for x86) to > emulate the > issue. > > When using gdb, I got the following backtrack. > > Thread 5 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7fffca15b700 (LWP 7637)] > 0x0000000000000000 in ?? () > (gdb) bt > #0 0x0000000000000000 in ?? () > #1 0x0000555555872492 in memory_region_oldmmio_read_accessor > (mr=0x5555567fa870, addr=1, value=0x7fffca158510, size=1, shift=0, > mask=255, attrs=...) at /home/liqiang02/qemu-devel/qemu/memory.c:409 > #2 0x000055555586f2dd in access_with_adjusted_size (addr=addr@entry=1, > value=value@entry=0x7fffca158510, size=size@entry=1, > access_size_min=<optimized out>, access_size_max=<optimized out>, > access_fn=0x555555872440 <memory_region_oldmmio_read_accessor>, > mr=0x5555567fa870, attrs=...) at > /home/liqiang02/qemu-devel/qemu/memory.c:593 > #3 0x0000555555873e90 in memory_region_dispatch_read1 (attrs=..., size=1, > pval=0x7fffca158510, addr=1, mr=0x5555567fa870) at > /home/liqiang02/qemu-devel/qemu/memory.c:1404 > #4 memory_region_dispatch_read (mr=mr@entry=0x5555567fa870, addr=1, > pval=pval@entry=0x7fffca158510, size=1, attrs=attrs@entry=...) at > /home/liqiang02/qemu-devel/qemu/memory.c:1423 > #5 0x0000555555821e42 in flatview_read_continue (fv=fv@entry=0x7fffbc03f370, > addr=addr@entry=1297, attrs=..., buf=<optimized out>, buf@entry=0x7ffff7fee000 > "", len=len@entry=1, addr1=<optimized out>, l=<optimized out>, > mr=0x5555567fa870) > at /home/liqiang02/qemu-devel/qemu/exec.c:3293 > #6 0x0000555555822006 in flatview_read (fv=0x7fffbc03f370, addr=1297, > attrs=..., buf=0x7ffff7fee000 "", len=1) at > /home/liqiang02/qemu-devel/qemu/exec.c:3331 > #7 0x000055555582211f in address_space_read_full (as=<optimized out>, > addr=addr@entry=1297, attrs=..., buf=buf@entry=0x7ffff7fee000 "", > len=len@entry=1) at /home/liqiang02/qemu-devel/qemu/exec.c:3344 > #8 0x000055555582225a in address_space_rw (as=<optimized out>, > addr=addr@entry=1297, attrs=..., attrs@entry=..., buf=buf@entry=0x7ffff7fee000 > "", len=len@entry=1, is_write=is_write@entry=false) > at /home/liqiang02/qemu-devel/qemu/exec.c:3374 > #9 0x0000555555886239 in kvm_handle_io (count=1, size=1, > direction=<optimized out>, data=<optimized out>, attrs=..., port=1297) at > /home/liqiang02/qemu-devel/qemu/accel/kvm/kvm-all.c:1731 > #10 kvm_cpu_exec (cpu=cpu@entry=0x5555566e9990) at > /home/liqiang02/qemu-devel/qemu/accel/kvm/kvm-all.c:1971 > #11 0x000055555585d3de in qemu_kvm_cpu_thread_fn (arg=0x5555566e9990) at > /home/liqiang02/qemu-devel/qemu/cpus.c:1257 > #12 0x00007fffdbd58494 in start_thread () from > /lib/x86_64-linux-gnu/libpthread.so.0 > #13 0x00007fffdba9aacf in clone () from /lib/x86_64-linux-gnu/libc.so.6 > > So I send out this path. > > But this time when I not use gdb, there is no segmentation. > > So this may not a issue. > > If who has a arm environment, he can try this, the PoC is just easy. just > read the 0x510 port with word. I don't understand your description of how you managed to trigger this SIGSEGV. FWIW, looking at the codebase, there's a good number of static MemoryRegionOps structures for which the "read_with_attrs" and "read" members are default-initialized to NULL. It seems unlikely they are all wrong. - exec.c: notdirty_mem_ops, readonly_mem_ops - hw/misc/debugexit.c: debug_exit_ops - hw/misc/hyperv_testdev.c: synic_test_sint_ops - hw/misc/pc-testdev.c: test_irq_ops, test_flush_ops - hw/pci-host/designware.c: designware_pci_host_msi_ops - hw/rdma/vmw/pvrdma_main.c: uar_ops - hw/sparc64/sun4u.c: power_mem_ops Laszlo
Hi Laszlo, Laszlo Ersek <lersek@redhat.com> 于2018年9月12日周三 下午6:36写道： > On 09/12/18 10:02, Li Qiang wrote: > > Hi, > > > > Marc-André Lureau <marcandre.lureau@gmail.com> 于2018年9月12日周三 下午3:16写道： > > > >> Hi > >> > >> On Wed, Sep 12, 2018 at 9:22 AM Li Qiang <liq3ea@gmail.com> wrote: > >>> > >>> The write/read should be paired, this can avoid the > >>> NULL-deref while the guest reads the fw_cfg port. > >>> > >>> Signed-off-by: Li Qiang <liq3ea@gmail.com> > >> > >> Do you have a reproducer and/or a backtrace? > >> memory_region_dispatch_write() checks if ops->write != NULL. > >> > > > > As far as I can see, the fw_cfg_mem is not used in x86 and used in arm. > > And from my impression, this will NULL read will be a issue. So I just > > omit the 'read' field in fw_cfg_comb_mem_ops(this is used for x86) to > > emulate the > > issue. > > > > When using gdb, I got the following backtrack. > > > > Thread 5 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 0x7fffca15b700 (LWP 7637)] > > 0x0000000000000000 in ?? () > > (gdb) bt > > #0 0x0000000000000000 in ?? () > > #1 0x0000555555872492 in memory_region_oldmmio_read_accessor > > (mr=0x5555567fa870, addr=1, value=0x7fffca158510, size=1, shift=0, > > mask=255, attrs=...) at /home/liqiang02/qemu-devel/qemu/memory.c:409 > > #2 0x000055555586f2dd in access_with_adjusted_size (addr=addr@entry=1, > > value=value@entry=0x7fffca158510, size=size@entry=1, > > access_size_min=<optimized out>, access_size_max=<optimized out>, > > access_fn=0x555555872440 <memory_region_oldmmio_read_accessor>, > > mr=0x5555567fa870, attrs=...) at > > /home/liqiang02/qemu-devel/qemu/memory.c:593 > > #3 0x0000555555873e90 in memory_region_dispatch_read1 (attrs=..., > size=1, > > pval=0x7fffca158510, addr=1, mr=0x5555567fa870) at > > /home/liqiang02/qemu-devel/qemu/memory.c:1404 > > #4 memory_region_dispatch_read (mr=mr@entry=0x5555567fa870, addr=1, > > pval=pval@entry=0x7fffca158510, size=1, attrs=attrs@entry=...) at > > /home/liqiang02/qemu-devel/qemu/memory.c:1423 > > #5 0x0000555555821e42 in flatview_read_continue (fv=fv@entry > =0x7fffbc03f370, > > addr=addr@entry=1297, attrs=..., buf=<optimized out>, buf@entry > =0x7ffff7fee000 > > "", len=len@entry=1, addr1=<optimized out>, l=<optimized out>, > > mr=0x5555567fa870) > > at /home/liqiang02/qemu-devel/qemu/exec.c:3293 > > #6 0x0000555555822006 in flatview_read (fv=0x7fffbc03f370, addr=1297, > > attrs=..., buf=0x7ffff7fee000 "", len=1) at > > /home/liqiang02/qemu-devel/qemu/exec.c:3331 > > #7 0x000055555582211f in address_space_read_full (as=<optimized out>, > > addr=addr@entry=1297, attrs=..., buf=buf@entry=0x7ffff7fee000 "", > > len=len@entry=1) at /home/liqiang02/qemu-devel/qemu/exec.c:3344 > > #8 0x000055555582225a in address_space_rw (as=<optimized out>, > > addr=addr@entry=1297, attrs=..., attrs@entry=..., buf=buf@entry > =0x7ffff7fee000 > > "", len=len@entry=1, is_write=is_write@entry=false) > > at /home/liqiang02/qemu-devel/qemu/exec.c:3374 > > #9 0x0000555555886239 in kvm_handle_io (count=1, size=1, > > direction=<optimized out>, data=<optimized out>, attrs=..., port=1297) at > > /home/liqiang02/qemu-devel/qemu/accel/kvm/kvm-all.c:1731 > > #10 kvm_cpu_exec (cpu=cpu@entry=0x5555566e9990) at > > /home/liqiang02/qemu-devel/qemu/accel/kvm/kvm-all.c:1971 > > #11 0x000055555585d3de in qemu_kvm_cpu_thread_fn (arg=0x5555566e9990) at > > /home/liqiang02/qemu-devel/qemu/cpus.c:1257 > > #12 0x00007fffdbd58494 in start_thread () from > > /lib/x86_64-linux-gnu/libpthread.so.0 > > #13 0x00007fffdba9aacf in clone () from /lib/x86_64-linux-gnu/libc.so.6 > > > > So I send out this path. > > > > But this time when I not use gdb, there is no segmentation. > > > > So this may not a issue. > > > > If who has a arm environment, he can try this, the PoC is just easy. just > > read the 0x510 port with word. > > I don't understand your description of how you managed to trigger this > SIGSEGV. > > FWIW, looking at the codebase, there's a good number of static > MemoryRegionOps structures for which the "read_with_attrs" and "read" > members are default-initialized to NULL. It seems unlikely they are all > wrong. > > I uses the debugexit. QEMU command: gdb --args qemu-system-x86_64 -m 2048 -hda /home/liqiang02/ubuntu1801.img -enable-kvm -vnc :100 -device isa-debug-exit guest: inw(0x501) We can get the following backtrack. Starting program: /usr/local/bin/qemu-system-x86_64 -m 2048 -hda /home/liqiang02/ubuntu1801.img -enable-kvm -vnc :100 -device isa-debug-exit [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7fffcde12700 (LWP 52824)] [New Thread 0x7fffcd41f700 (LWP 52825)] WARNING: Image format was not specified for '/home/liqiang02/ubuntu1801.img' and probing guessed raw. Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. Specify the 'raw' format explicitly to remove the restrictions. [New Thread 0x7fffcca3c700 (LWP 52826)] [New Thread 0x7fff463ff700 (LWP 52828)] [Thread 0x7fffcd41f700 (LWP 52825) exited] [New Thread 0x7fffcd41f700 (LWP 52857)] [Thread 0x7fffcd41f700 (LWP 52857) exited] [New Thread 0x7fffcd41f700 (LWP 52935)] Thread 4 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffcca3c700 (LWP 52826)] 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in ?? () #1 0x00005555557c1f81 in memory_region_oldmmio_read_accessor (mr=0x5555577b32b0, addr=0, value=0x7fffcca39568, size=2, shift=0, mask=65535, attrs=...) at /home/liqiang02/qemu_max_cpu/qemu-2.8/memory.c:409 #2 0x00005555557c2697 in access_with_adjusted_size (addr=0, value=0x7fffcca39568, size=2, access_size_min=1, access_size_max=4, access=0x5555557c1f31 <memory_region_oldmmio_read_accessor>, mr=0x5555577b32b0, attrs=...) at /home/liqiang02/qemu_max_cpu/qemu-2.8/memory.c:592 #3 0x00005555557c4aa2 in memory_region_dispatch_read1 (mr=0x5555577b32b0, addr=0, pval=0x7fffcca39568, size=2, attrs=...) at /home/liqiang02/qemu_max_cpu/qemu-2.8/memory.c:1254 #4 0x00005555557c4b26 in memory_region_dispatch_read (mr=0x5555577b32b0, addr=0, pval=0x7fffcca39568, size=2, attrs=...) at /home/liqiang02/qemu_max_cpu/qemu-2.8/memory.c:1273 #5 0x00005555557708ba in address_space_read_continue (as=0x5555562cc760 <address_space_io>, addr=1281, attrs=..., buf=0x7ffff7fee000 "", len=2, addr1=0, l=2, mr=0x5555577b32b0) at /home/liqiang02/qemu_max_cpu/qemu-2.8/exec.c:2692 #6 0x0000555555770a53 in address_space_read_full (as=0x5555562cc760 <address_space_io>, addr=1281, attrs=..., buf=0x7ffff7fee000 "", len=2) at /home/liqiang02/qemu_max_cpu/qemu-2.8/exec.c:2743 #7 0x0000555555770b15 in address_space_read (len=2, buf=0x7ffff7fee000 "", attrs=..., addr=1281, as=0x5555562cc760 <address_space_io>) at /home/liqiang02/qemu_max_cpu/qemu-2.8/include/exec/memory.h:1527 #8 address_space_rw (as=0x5555562cc760 <address_space_io>, addr=1281, attrs=..., buf=0x7ffff7fee000 "", len=2, is_write=false) at /home/liqiang02/qemu_max_cpu/qemu-2.8/exec.c:2757 #9 0x00005555557bea59 in kvm_handle_io (port=1281, attrs=..., data=0x7ffff7fee000, direction=0, size=2, count=1) at /home/liqiang02/qemu_max_cpu/qemu-2.8/kvm-all.c:1800 #10 0x00005555557bef5f in kvm_cpu_exec (cpu=0x5555568279c0) at /home/liqiang02/qemu_max_cpu/qemu-2.8/kvm-all.c:1958 #11 0x00005555557a5d5f in qemu_kvm_cpu_thread_fn (arg=0x5555568279c0) at /home/liqiang02/qemu_max_cpu/qemu-2.8/cpus.c:998 #12 0x00007fffdbf89494 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #13 0x00007fffdbccbacf in clone () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) Seems the root cause is in 'memory_region_oldmmio_read_accessor '. Anyway I have sent out another patch to address issue. Thanks, Li Qiang > - exec.c: notdirty_mem_ops, readonly_mem_ops > - hw/misc/debugexit.c: debug_exit_ops > - hw/misc/hyperv_testdev.c: synic_test_sint_ops > - hw/misc/pc-testdev.c: test_irq_ops, test_flush_ops > - hw/pci-host/designware.c: designware_pci_host_msi_ops > - hw/rdma/vmw/pvrdma_main.c: uar_ops > - hw/sparc64/sun4u.c: power_mem_ops > > Laszlo >
On 9/12/18 7:33 AM, Li Qiang wrote: >>>> >>>> Do you have a reproducer and/or a backtrace? >>>> memory_region_dispatch_write() checks if ops->write != NULL. >>>> >> FWIW, looking at the codebase, there's a good number of static >> MemoryRegionOps structures for which the "read_with_attrs" and "read" >> members are default-initialized to NULL. It seems unlikely they are all >> wrong. >> >> > I uses the debugexit. > > QEMU command: gdb --args qemu-system-x86_64 -m 2048 -hda > /home/liqiang02/ubuntu1801.img -enable-kvm -vnc :100 -device isa-debug-exit > > guest: inw(0x501) > > We can get the following backtrack. > > Starting program: /usr/local/bin/qemu-system-x86_64 -m 2048 -hda > /home/liqiang02/ubuntu1801.img -enable-kvm -vnc :100 -device isa-debug-exit > Thread 4 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7fffcca3c700 (LWP 52826)] > 0x0000000000000000 in ?? () > (gdb) bt > #0 0x0000000000000000 in ?? () > #1 0x00005555557c1f81 in memory_region_oldmmio_read_accessor > (mr=0x5555577b32b0, addr=0, value=0x7fffcca39568, size=2, shift=0, > mask=65535, attrs=...) at /home/liqiang02/qemu_max_cpu/qemu-2.8/memory.c:409 Doesn't that mean we should fix memory_region_oldmmio_read_accessor() to deal with a NULL callback, rather than hacking up a large number of devices to supply a no-op callback?
diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c index d79a568f54..6de7809f1a 100644 --- a/hw/nvram/fw_cfg.c +++ b/hw/nvram/fw_cfg.c @@ -434,6 +434,11 @@ static bool fw_cfg_data_mem_valid(void *opaque, hwaddr addr, return addr == 0; } +static uint64_t fw_cfg_ctl_mem_read(void *opaque, hwaddr addr, unsigned size) +{ + return 0; +} + static void fw_cfg_ctl_mem_write(void *opaque, hwaddr addr, uint64_t value, unsigned size) { @@ -468,6 +473,7 @@ static bool fw_cfg_comb_valid(void *opaque, hwaddr addr, } static const MemoryRegionOps fw_cfg_ctl_mem_ops = { + .read = fw_cfg_ctl_mem_read, .write = fw_cfg_ctl_mem_write, .endianness = DEVICE_BIG_ENDIAN, .valid.accepts = fw_cfg_ctl_mem_valid,
The write/read should be paired, this can avoid the NULL-deref while the guest reads the fw_cfg port. Signed-off-by: Li Qiang <liq3ea@gmail.com> --- hw/nvram/fw_cfg.c | 6 ++++++ 1 file changed, 6 insertions(+)