On 19/02/2019 09:10, Anisse Astier wrote: > Hi, > > I discovered this last month, before Jean-Philippe's patch series was > merged. This issue is now resolved, but I thought it might be of > interest to distributions to update their package. I have not assessed > the security impact, but it might be a good idea to update kvmtool > anyway. > > Using standard ubuntu images, it's possible to crash kvmtool by > inserting/removing the virtio-blk module. > > I boot with rdinit=/bin/sh, then run the following commands: > > mkdir sys; mount -t sysfs s /sys > modprobe virtio-net > modprobe virtio-blk; modprobe -r virtio-blk > modprobe virtio-blk > > This might be related to the lack of uninit of virtio devices, since I > can't reproduce the issue after applying Jean-Philippe's patch series > "Implement reset of virtio devices" (now merged in git) : > https://marc.info/?l=android-virt&m=154712959225769&w=4 > > I packaged the ubuntu kernel and a reduced initramfs to ease reproducing > the issue (the init script does it automatically): > https://anisse.astier.eu/static/crash-kvmtool.tar.xz > > I haven't look in detail at the issue, but it crashes after memory has > been corrupted, the gdb stack isn't really helpful. Yes, for module reloading (as well as firmware boot and kexec) you need reset support. In more details, since the virtio state isn't reinitialized on the device side, device and driver may have an inconsistent view of the virtqueue on second load, so the device will fetch descriptors that haven't been published by the driver. In the best-case scenario the guest detects the inconsistency and stops probing. But it could as well lead to corruption in host userspace or in the guest. Upgrading to a recent kvmtool should solve this. Thanks, Jean
