Comment 2 for bug 1878253

On 7/4/20 12:14 PM, Launchpad Bug Tracker wrote:
> You have been subscribed to a public bug by Philippe Mathieu-Daudé (philmd):
>
> Hello,
> 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 /home/alxndr/Development/qemu/include/exec/memory.h:693:12
> #1 0x55e0f562bafd in address_space_write /home/alxndr/Development/qemu/exec.c:3267:14
> #2 0x55e0f562dd9c in address_space_unmap /home/alxndr/Development/qemu/exec.c:3592:9
> #3 0x55e0f5ab8277 in dma_memory_unmap /home/alxndr/Development/qemu/include/sysemu/dma.h:145:5
> #4 0x55e0f5ab8277 in dma_blk_unmap /home/alxndr/Development/qemu/dma-helpers.c:104:9
> #5 0x55e0f5ab8277 in dma_blk_cb /home/alxndr/Development/qemu/dma-helpers.c:139:5
> #6 0x55e0f617a6b8 in blk_aio_complete /home/alxndr/Development/qemu/block/block-backend.c:1398:9
> #7 0x55e0f617a6b8 in blk_aio_complete_bh /home/alxndr/Development/qemu/block/block-backend.c:1408:5
> #8 0x55e0f6355efb in aio_bh_call /home/alxndr/Development/qemu/util/async.c:136:5
> #9 0x55e0f6355efb in aio_bh_poll /home/alxndr/Development/qemu/util/async.c:164:13
> #10 0x55e0f63608ce in aio_dispatch /home/alxndr/Development/qemu/util/aio-posix.c:380:5
> #11 0x55e0f635799a in aio_ctx_dispatch /home/alxndr/Development/qemu/util/async.c:306:5
> #12 0x7f16e85d69ed in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e9ed)
> #13 0x55e0f635e384 in glib_pollfds_poll /home/alxndr/Development/qemu/util/main-loop.c:219:9
> #14 0x55e0f635e384 in os_host_main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:242:5
> #15 0x55e0f635e384 in main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:518:11
> #16 0x55e0f593d676 in qemu_main_loop /home/alxndr/Development/qemu/softmmu/vl.c:1664:9
> #17 0x55e0f6267c6a in main /home/alxndr/Development/qemu/softmmu/main.c:49:5
> #18 0x7f16e7186e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16
> #19 0x55e0f55727b9 in _start (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x9027b9)
>
> AddressSanitizer can not provide additional info.
> SUMMARY: AddressSanitizer: SEGV /home/alxndr/Development/qemu/include/exec/memory.h:693:12 in address_space_to_flatview
>
> 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
> EOF
>

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.

--js

> 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.
> -Alex
>
> ** Affects: qemu
> Importance: Undecided
> Status: New
>