Re: [PATCH 1/5] migration: Fix possible overflow in vmstate_handle_alloc()
Fabiano Rosas <[email protected]>
| Newsgroups | gmane.comp.emulators.qemu,gmane.comp.emulators.qemu.stable |
|---|---|
| Message-ID | <[email protected]> |
Peter Xu <[email protected]> writes: > Migration incoming side almost always trusted the stream data and allows > allocation to happen with whatever size received. With it, malicious > migration stream can manipulate destination QEMU behavior on g_malloc(), in > path of vmstate_handle_alloc() on specific VMSD fields. Fix it by limiting > all sizes with int32_t positive values (INT_MAX) explicitly. > > We have quite a few bug reports recently leveraging this defect. It can be > reproduced in many ways for (I think) all archs binaries, but the simplest > reproducer is: > > $ hexdump -C ./vm.img > 00000000 51 45 56 4d 00 00 00 03 07 80 00 00 00 00 00 00 |QEVM............| > > $ ./qemu-system-x86_64 -incoming file:./vm.img > VNC server running on ::1:5900 > qemu-system-x86_64: GLib: ../glib/gmem.c:106: failed to allocate 18446744071562067968 bytes > Aborted (core dumped) ./qemu-system-x86_64 -incoming file:./vm.img > > We could assert here, but since we have errp right above the stack this > patch routes the errp over to allow destination QEMU fail gracefully. This > means there's no way to DoS coredumpctl as well because we don't generate > core dumps at all. The output message could also hopefully help triage > issues when it's not a malicious stream but only wrong image used. > > When at this, making sure multiplex also won't overflow. > > After patched: > > $ ./qemu-system-x86_64 -incoming file:./vm.img > VNC server running on ::1:5900 > qemu-system-x86_64: load of migration failed: Invalid argument: vmstate_size: VMState field 'name' overflow > > Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3805 > Reported-by: Feifan Qian <[email protected]> > Reported-by: dong ling (@dongling226655) > Cc: qemu-stable <[email protected]> > Cc: Peter Maydell <[email protected]> > Cc: Fabiano Rosas <[email protected]> > Signed-off-by: Peter Xu <[email protected]> Reviewed-by: Fabiano Rosas <[email protected]>