Re: [Qemu-devel] Crash when booting KDE Neon using qxl-vga

[Leonardo Soares Müller]

Thank you for testing this, the last update greatly improved the
situation. libspice-server1 updated, so I rebuilt QEMU. The
libspice-server1 0.14.0-1ubuntu2.4 change log is:

  * SECURITY UPDATE: off-by-one error in memslot_get_virt
    - debian/patches/CVE-2019-3813.patch: fix checks in server/memslot.c,
      add tests to server/tests/test-qxl-parsing.c.
    - CVE-2019-3813
  * debian/tests/automated-tests: fix incorrect test name, don't fail on
    build writing to stderr.

The errors on terminal are:

(qemu:11683): Spice-CRITICAL **: 18:39:40.747:
memslot.c:111:memslot_get_virt: slot_id 255 too big, addr=ff000000ff000000
Abortado (imagem do núcleo gravada)

The function that was changed with the last update seems to be the exact
same function that was causing the crash. Now the crash happens ONLY in
the first execution. All subsequent executions work correctly.

While the guest crashes on the first execution, it seems the guest file
system is resilient enough to suffer no damages from the crash on the
first boot and subsequent boots all seem perfect.

I installed the debug symbols for libglib-2.0 too, hopefully the
additional debug messages have some useful information. From the first
execution that crashes (gtk,gl=on and gtk had the same result):

qemu-system-x86_64 -accel kvm -cpu host -smp cores=2,threads=1 -m 2048
-hda neonbroken.qcow2 -device qxl-vga,xres=1366,yres=768,addr=2 -display
gtk,gl=on -monitor vc -serial vc -device qemu-xhci,addr=3 -netdev
user,id=net0 -device e1000,netdev=net0,addr=4 -bios /usr/share/ovmf/OVMF.fd

id 0, group 0, virt start 0, virt end ffffffffffffffff, generation 0,
delta 0
id 1, group 1, virt start 7fff1fe00000, virt end 7fff23dfe000,
generation 0, delta 7fff1fe00000
id 2, group 1, virt start 7fff1bc00000, virt end 7fff1fc00000,
generation 0, delta 7fff1bc00000

(qemu:1937): Spice-CRITICAL **: 20:17:21.623:
memslot.c:111:memslot_get_virt: slot_id 255 too big, addr=ff000000ff000000

(gdb) bt
#0  0x00007ffff0371e97 in __GI_raise (address@hidden) at
../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007ffff0373801 in __GI_abort () at abort.c:79
#2  0x00007ffff116fcc9 in spice_logv (log_domain=0x7ffff11da9f5 "Spice",
args=0x7fff36028cb0, format=0x7ffff11e1c5b "slot_id %d too big,
addr=%lx", function=0x7ffff11e1d90 <__FUNCTION__.15594>
"memslot_get_virt", strloc=0x7ffff11e1c78 "memslot.c:111",
log_level=G_LOG_LEVEL_CRITICAL) at log.c:183
#3  0x00007ffff116fcc9 in spice_log
(address@hidden,
address@hidden "memslot.c:111",
address@hidden <__FUNCTION__.15594>
"memslot_get_virt", address@hidden "slot_id %d too
big, addr=%lx") at log.c:196
#4  0x00007ffff11353b8 in memslot_get_virt
(address@hidden, address@hidden,
address@hidden, address@hidden,
address@hidden) at memslot.c:111
#5  0x00007ffff113e7d0 in red_get_image
(address@hidden, address@hidden,
addr=<optimized out>, address@hidden, address@hidden)
at red-parse-qxl.c:512
#6  0x00007ffff113ea76 in red_get_copy_ptr
(address@hidden, address@hidden,
address@hidden, qxl=0x7fff1fe0107b, address@hidden)
at red-parse-qxl.c:680
#7  0x00007ffff113f9a1 in red_get_native_drawable (flags=<optimized
out>, addr=<optimized out>, red=<optimized out>, group_id=<optimized
out>, slots=<optimized out>) at red-parse-qxl.c:1072
#8  0x00007ffff113f9a1 in red_get_drawable
(address@hidden, group_id=1,
address@hidden, addr=<optimized out>, flags=0) at
red-parse-qxl.c:1206
#9  0x00007ffff11523cd in red_process_display (worker=0x5555579bcd80,
ring_is_empty=0x7fff36028f9c) at red-worker.c:224
#10 0x00007ffff1150d21 in flush_commands
(address@hidden, red_channel=0x5555579b9210
[DisplayChannel], address@hidden
<red_process_display>) at red-worker.c:315
#11 0x00007ffff1150e58 in flush_display_commands
(address@hidden) at red-worker.c:352
#12 0x00007ffff11514bf in flush_all_qxl_commands (worker=0x5555579bcd80)
at red-worker.c:367
#13 0x00007ffff11514bf in destroy_primary_surface
(worker=0x5555579bcd80, surface_id=0) at red-worker.c:558
#14 0x00007ffff111f4f1 in dispatcher_handle_single_read
(dispatcher=0x555556a1d1c0 [Dispatcher]) at dispatcher.c:284
#15 0x00007ffff111f4f1 in dispatcher_handle_recv_read
(dispatcher=0x555556a1d1c0 [Dispatcher]) at dispatcher.c:304
#16 0x00007ffff1125d7b in watch_func (source=<optimized out>,
condition=<optimized out>, data=0x5555579bcf60) at event-loop.c:128
#17 0x00007ffff47911f5 in g_main_dispatch (context=0x5555579bce70) at
../../../../glib/gmain.c:3176
#18 0x00007ffff47911f5 in g_main_context_dispatch
(address@hidden) at ../../../../glib/gmain.c:3829
#19 0x00007ffff47915c0 in g_main_context_iterate
(context=0x5555579bce70, address@hidden, address@hidden,
self=<optimized out>) at ../../../../glib/gmain.c:3902
#20 0x00007ffff47918d2 in g_main_loop_run (loop=0x7fff14002530) at
../../../../glib/gmain.c:4098
#21 0x00007ffff1151b3a in red_worker_main (arg=0x5555579bcd80) at
red-worker.c:1372
#22 0x00007ffff072b6db in start_thread (arg=0x7fff3602c700) at
pthread_create.c:463
#23 0x00007ffff045488f in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Às 18:28 de 01/02/2019, Dr. David Alan Gilbert escreveu:
> 
> Right yes; as you say with hda it's fine;  I've pointed Paolo at
> this one.
> 
> As for the original crash; I can't reproduce it here (On Fedora 29,
> head qemu):
> ./x86_64-softmmu/qemu-system-x86_64 -cpu host  -M pc,accel=kvm -smp 3 -m 8G 
> -drive if=ide,file=/home/vmimages/kde-neon.qcow2 -display gtk,gl=on -device 
> qemu-xhci,addr=3 -device qxl-vga,xres=1366,yres=768,addr=4 -bios 
> /usr/share/OVMF/OVMF_CODE.fd
> 
> Dave
> 
> --
> Dr. David Alan Gilbert / address@hidden / Manchester, UK
>