Hello Gerd, On Thu, 28 Aug 2014 07:57:17 GMT, kra...@redhat.com wrote: > In case the memory area happens to hit unmapped pages qemu segfaults. > => DoS > > The guest can't modify host memory though, so I don't think this can be > used by the guest to compromise the host.
I was finally able to reproduce the issue on a rhel-7 machine. Looking through the stack trace, the SIGSEGV occurs while doing memset(2) in red_create_surface() routine of the spice-server library. That is host memory write instigated from a guest. Here the length value is consistent: 35389440. Nonetheless, it is not very clear how & where did that value come from. Upon starting the reproducer from Laszlo, it creates 5 threads. One(or all) of them calls red_worker_main -> worker->watches[i].watch_func(worker->poll_fds[i].fd, events, worker->watches[i].watch_func_opaque); -> void dispatcher_handle_recv_read(Dispatcher *dispatcher) -> dispatcher_handle_single_read(dispatcher) -> msg->handler(dispatcher->opaque, (void *)payload); -> handle_dev_create_primary_surface(void *opaque, void *payload) -> dev_create_primary_surface(worker, msg->surface_id, msg->surface); -> red_create_surface (worker, 0, surface.width, surface.height, ...) There is a gap in the sequence above wherein it's not clear which function is invoked by - watch_func(...), which in turn calls dispatcher_handle_recv_read(). Could the memset(2) length argument controlled by an end application in the guest? If so, that could be used to write/set arbitrary memory bytes on the host, without crashing the Qemu, as the crash requires it to hit an unmapped memory area. Could an unprivileged user/process on the guest trigger this crash in Qemu? --- Prasad J Pandit / Red Hat Product Security
