0x00背景
安全娱乐圈媒体Freebuf对该漏洞的有关报道：
提供的POC没有触发崩溃，在MJ0011的博客给出了修改后可以使qemu崩溃的poc。详见：
0x01漏洞重现
注：qemu的用户交互性体验相对于vmware来说，极差
a.Linux 的qemu虚拟机
环境:
Win 10 物理机 + qemu-system-i386.exe (2.0.50) + CentOS 6.3虚拟机
Linux 因为在用户层就可以直接操作端口，所以在linux虚拟机中将MJ给的POC保存成一个C文件，用gcc编译后运行，就可以看到qemu崩溃了：
b.Windows的qemu虚拟机
环境:
Win 10 物理机 + Qemu Manager 7.0 + WinXP虚拟机
Windows因为不可以在用户层直接和端口操作，需要借助驱动，所以就存在了和物理机的交互:驱动加载工具和编译好的驱动程序。
测试的过程中，使用了Qemu Manager 7.0来建立共享文件夹。在物理机设置一个共享文件夹，然后就可在windows虚拟机的网上邻居访问了：
编写的驱动关键代码，换成对应对端口操作的函数就好了：
物理机中用windbg附加到qemu进程后，在xp虚拟机中加载驱动后，就可以观察到windbg捕获到异常了:
注：如果不用windbg附加到qemu.exe进程的话，那么看到的是qemu mannager把虚拟机给关了。
0x02分析
MJ的文章对漏洞成因进行了较为详细的分析了，具体的情况可以查看其blog。下面进行简要的说明:
qemu接受到FIFO命令后，会先调用fdctrl_write_data 函数，该函数会确保fdctrl的状态是可写入的，才会进行下一步操作。
outb(0x8e,0x3f5)对应的函数为fdctrl_handle_drive_specification_command:
因为 fdctrl->fifo[fdctrl->data_pos - 1] 是我们可控的，加上fdctrl ->data_len =6，不可能大于7,所以可以绕过这两个对fdctrl写入状态的改写，其状态还是可以被写入的。
而接受写入数据buffer fdctrl->fifo的大小为0x1000 bytes，poc中对其进行不断的写入，也就发生了越界写了。