vpc file causes qemu-img to consume lots of time and memory

[Richard Jones]

The attached vpc file causes 'qemu-img info' to consume 3 or 4 seconds of CPU time and 1.3 GB of heap, causing a minor denial of service.

$ /usr/bin/time ~/d/qemu/qemu-img info afl12.img
block-vpc: The header checksum of 'afl12.img' is incorrect.
qemu-img: Could not open 'afl12.img': block-vpc: free_data_block_offset points after the end of file. The image has been truncated.
1.19user 3.15system 0:04.35elapsed 99%CPU (0avgtext+0avgdata 1324504maxresident)k
0inputs+0outputs (0major+327314minor)pagefaults 0swaps

The file was found using american-fuzzy-lop.

[Richard Jones (rjones-redhat)]

This slightly modified example takes about 7 seconds and 2 GB of heap:

$ /usr/bin/time ~/d/qemu/qemu-img info /mnt/scratch/afl13.img
block-vpc: The header checksum of '/mnt/scratch/afl13.img' is incorrect.
qemu-img: Could not open '/mnt/scratch/afl13.img': block-vpc: free_data_block_offset points after the end of file. The image has been truncated.
1.84user 5.72system 0:07.59elapsed 99%CPU (0avgtext+0avgdata 2045496maxresident)k
8inputs+0outputs (0major+507536minor)pagefaults 0swaps

[Thomas Huth (th-huth)]

Is there still something left to do here, or could we close this ticket nowadays?

[Richard Jones (rjones-redhat)]

I suspect this bug is probably still around, and if not then this class of bugs is certainly still around. What we have done in management tools like Open Stack is to confine qemu-img using simple ulimits when inspecting any untrusted image, and that solves the problem so it's probably fine to close this bug now.

[Launchpad Janitor (janitor)]

[Expired for QEMU because there has been no activity for 60 days.]