[Top][All Lists]

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

Re: [Bug 1878253] [NEW] null-ptr dereference in address_space_to_flatvie

From: John Snow
Subject: Re: [Bug 1878253] [NEW] null-ptr dereference in address_space_to_flatview through ide
Date: Wed, 22 Jul 2020 00:28:00 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

On 7/4/20 12:14 PM, Launchpad Bug Tracker wrote:
You have been subscribed to a public bug by Philippe Mathieu-Daudé (philmd):

While fuzzing, I found an input that triggers a null-ptr dereference in
address_space_to_flatview through ide:

==31699==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000020 (pc 
0x55e0f562bafd bp 0x7ffee92355b0 sp 0x7ffee92354e0 T0)
==31699==The signal is caused by a READ memory access.
==31699==Hint: address points to the zero page.
     #0 0x55e0f562bafd in address_space_to_flatview 
     #1 0x55e0f562bafd in address_space_write 
     #2 0x55e0f562dd9c in address_space_unmap 
     #3 0x55e0f5ab8277 in dma_memory_unmap 
     #4 0x55e0f5ab8277 in dma_blk_unmap 
     #5 0x55e0f5ab8277 in dma_blk_cb 
     #6 0x55e0f617a6b8 in blk_aio_complete 
     #7 0x55e0f617a6b8 in blk_aio_complete_bh 
     #8 0x55e0f6355efb in aio_bh_call 
     #9 0x55e0f6355efb in aio_bh_poll 
     #10 0x55e0f63608ce in aio_dispatch 
     #11 0x55e0f635799a in aio_ctx_dispatch 
     #12 0x7f16e85d69ed in g_main_context_dispatch 
     #13 0x55e0f635e384 in glib_pollfds_poll 
     #14 0x55e0f635e384 in os_host_main_loop_wait 
     #15 0x55e0f635e384 in main_loop_wait 
     #16 0x55e0f593d676 in qemu_main_loop 
     #17 0x55e0f6267c6a in main 
     #18 0x7f16e7186e0a in __libc_start_main 
     #19 0x55e0f55727b9 in _start 

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV 
/home/alxndr/Development/qemu/include/exec/memory.h:693:12 in 

I can reproduce it in qemu 5.0 using:

cat << EOF | ~/Development/qemu/build/i386-softmmu/qemu-system-i386 -M pc 
-nographic -drive file=null-co://,if=ide,cache=writeback,format=raw -nodefaults 
-display none -nographic -qtest stdio -monitor none -serial none
outl 0xcf8 0x80000920
outl 0xcfc 0xc001
outl 0xcf8 0x80000924
outl 0xcf8 0x80000904
outw 0xcfc 0x7
outb 0x1f7 0xc8
outw 0x3f6 0xe784
outw 0x3f6 0xeb01
outb 0xc005 0x21
write 0x2103 0x1 0x4e
outb 0xc000 0x1b
outw 0x1f7 0xff35

Willing to bet this is the same root cause as some of the others, because of this sequence:

outb 0x1f7 0xc8 (Issues a command)
outb 0x3f6 0x84 [1000 0100] - Arms SRST
outb 0x3f6 0x01 [0000 0001] - Issues SRST
outb 0x1f7 0x35 - Issues another command

The problem continues to be that SRST allows new commands to come in while the state machine is still stuck on the first command.


I also attached the traces to this launchpad report, in case the
formatting is broken:

qemu-system-i386 -M pc -nographic -drive file=null-
co://,if=ide,cache=writeback,format=raw -nodefaults -display none
-nographic -qtest stdio -monitor none -serial none < attachment

Please let me know if I can provide any further info.

** Affects: qemu
      Importance: Undecided
          Status: New

reply via email to

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