Bug 733135 - qemu-img crashes on corrupted img file
Summary: qemu-img crashes on corrupted img file
Keywords:
Status: CLOSED DUPLICATE of bug 1079339
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Kevin Wolf
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-24 21:03 UTC by Eric Blake
Modified: 2014-04-23 13:24 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-04-23 13:24:20 UTC


Attachments (Terms of Use)
corrupted qcow2 file (832.50 KB, application/octet-stream)
2011-08-24 21:03 UTC, Eric Blake
no flags Details

Description Eric Blake 2011-08-24 21:03:48 UTC
Created attachment 519719 [details]
corrupted qcow2 file

Description of problem:
In playing with snapshot support in libvirt, I managed to somehow corrupt a qcow2 file (no important data exists on the disk; it was created solely for experimenting with qemu-img and qemu snapshot-blkdev).  The corruption is such that trying to create a new snapshot made qemu-img dump core.

Qemu-img should detect the file as corrupted, rather than dump core.  I'm hoping that this core dump is not the sign of something exploitable.

Version-Release number of selected component (if applicable):
qemu-img-0.12.1.2-2.183.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1. download the attached top.img
2. qemu-img snapshot -l top.img
3. qemu-img snapshot -c foo top.img
  
Actual results:
2.# qemu-img snapshot -l /mnt/backup/opt/libvirt/images/top.img 
Snapshot list:
ID        TAG                 VM SIZE                DATE       VM CLOCK
5         testing2                  0 2011-08-18 09:48:52   00:00:00.000
6         testing3                  0 2011-08-18 13:32:15   00:45:03.133
8         2                         0 2011-08-24 12:30:38   00:00:00.000
3.# qemu-img snapshot -c foo /mnt/backup/opt/libvirt/images/top.img 
Segmentation fault (core dumped)


Expected results:
qemu-img should never dump core

Additional info:
Let me know if you need the backing file.

Comment 2 Eric Blake 2011-08-24 21:14:18 UTC
Note that the following sequence seems to repair the corruption:

# qemu-img snapshot -d 2 /mnt/backup/opt/libvirt/images/top.img 
# qemu-img snapshot -c foo /mnt/backup/opt/libvirt/images/top.img 
Segmentation fault (core dumped)
# qemu-img snapshot -c 2 /mnt/backup/opt/libvirt/images/top.img 
# qemu-img snapshot -l /mnt/backup/opt/libvirt/images/top.img 
Snapshot list:
ID        TAG                 VM SIZE                DATE       VM CLOCK
5         testing2                  0 2011-08-18 09:48:52   00:00:00.000
6         testing3                  0 2011-08-18 13:32:15   00:45:03.133
7         2                         0 2011-08-24 15:06:28   00:00:00.000
# qemu-img snapshot -c foo /mnt/backup/opt/libvirt/images/top.img 
# qemu-img snapshot -l /mnt/backup/opt/libvirt/images/top.img 
Snapshot list:
ID        TAG                 VM SIZE                DATE       VM CLOCK
5         testing2                  0 2011-08-18 09:48:52   00:00:00.000
6         testing3                  0 2011-08-18 13:32:15   00:45:03.133
7         2                         0 2011-08-24 15:06:28   00:00:00.000
8         foo                       0 2011-08-24 15:06:36   00:00:00.000

I have no idea what caused the original problem, or why this additional playing with the file seemed to straighten things out.

I'm also a bit worried that 'qemu-img snapshot -d nnn file' when 'nnn' is an integer can remove either a tag or an id.  Is there any way to fine-tune which gets removed?  Note that libvirt defaults to creating numeric tags (although they are named with large numbers, as in seconds since epoch, so it would take a lot of effort to get id up that high), and I'm worried that the ambiguity on which snapshot gets deleted could cause problems.

Comment 6 Suqin Huang 2012-07-25 07:44:07 UTC
Hi Eric,
Can not open the file, can you provide the image again.

[root@intel-8400-8-1 ~]# qemu-img snapshot -l top.img 
qemu-img: Could not open 'top.img'


qemu-kvm-rhev-0.12.1.2-2.298.el6_3.x86_64

Comment 7 Eric Blake 2012-07-25 13:50:43 UTC
That's the right file, and I get the same behavior with qemu-img-1.1.0-9.fc17.x86_64:

$ qemu-img info Downloads/top.img 
image: Downloads/top.img
file format: qcow2
virtual size: 10M (10485760 bytes)
disk size: 836K
cluster_size: 65536
backing file: middle.img (actual path: Downloads/middle.img)
Snapshot list:
ID        TAG                 VM SIZE                DATE       VM CLOCK
5         testing2                  0 2011-08-18 09:48:52   00:00:00.000
6         testing3                  0 2011-08-18 13:32:15   00:45:03.133
8         2                         0 2011-08-24 12:30:38   00:00:00.000
$ qemu-img snapshot -l Downloads/top.img 
qemu-img: Could not open 'Downloads/top.img': No such file or directory
$ touch Downloads/middle.img
$ qemu-img snapshot -l Downloads/top.img 
Snapshot list:
ID        TAG                 VM SIZE                DATE       VM CLOCK
5         testing2                  0 2011-08-18 09:48:52   00:00:00.000
6         testing3                  0 2011-08-18 13:32:15   00:45:03.133
8         2                         0 2011-08-24 12:30:38   00:00:00.000


The reason 'snapshot -l' is failing appears to be because you don't have the backing file present, but that is evidence of a bad error message in qemu-img (it should be complaining about the missing backing file, not about top.img itself).

Comment 12 Kevin Wolf 2014-04-23 13:24:20 UTC
This was fixed with one of the block audit patches, closing.

*** This bug has been marked as a duplicate of bug 1079339 ***


Note You need to log in before you can comment on or make changes to this bug.