Bug 1208555 - qcow2_update_header corrupts metadata if backing file was overridden
Summary: qcow2_update_header corrupts metadata if backing file was overridden
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Kevin Wolf
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 731134
TreeView+ depends on / blocked
 
Reported: 2015-04-02 14:05 UTC by Eric Blake
Modified: 2015-12-04 16:33 UTC (History)
11 users (show)

Fixed In Version: qemu-2.3.0
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-04 16:33:19 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:2546 normal SHIPPED_LIVE qemu-kvm-rhev bug fix and enhancement update 2015-12-04 21:11:56 UTC

Description Eric Blake 2015-04-02 14:05:39 UTC
Description of problem:
If a qcow2 file is opened with an explicit backing override (such as for fd passing, -drive file=...,backing.file.filename=/dev/fdset/2), then operations on that file that rewrite the metadata will change the backing file name to the override, instead of the desired action of leaving it untouched.

See also: https://lists.gnu.org/archive/html/qemu-devel/2015-04/msg00280.html


Version-Release number of selected component (if applicable):
still present in upstream qemu.git as of commit 2.3-rc2

How reproducible:
100%

Steps to Reproduce:
1. see the referenced thread; that used HMP, but I suspect that a scenario can be generated using only QMP
2.
3.

Actual results:
the qcow2 file backing name is rewritten to a bogus /dev/fdset reference, losing information if one does not remember which file was assigned to that fdset

Expected results:
when updating qcow2 metadata, the original backing name should be preserved even when the backing file was opened via fd override


Additional info:
libvirt hopes to start using fdset overrides for additional security on NFS, so this needs to work correctly

Comment 2 Eric Blake 2015-04-02 15:21:41 UTC
see also bug 1208587

Comment 3 Kevin Wolf 2015-05-04 10:03:26 UTC
This was fixed in 2.3.0-rc3, so we got the fix with the recent rebase.

I confirmed that RHEL qemu-kvm and RHEL 7.1 qemu-kvm-rhev are not affected.

Comment 6 Xiaoqing Wei 2015-07-06 03:00:24 UTC
[root@dhcp-11-50 qemu-kvm-rhev7]# git log --oneline v2.2.0..v2.3.0-rc3 block/qcow2.c VERSION
b8df920 Update version for v2.3.0-rc3 release
e4603fe qcow2: Fix header update with overridden backing file
^ the commit message from Kevin which fixed this bug


f2155a0 Update version for v2.3.0-rc2 release
054903a Update version for v2.3.0-rc1 release
cd232ac Update version for v2.3.0-rc0 release
87b86e7 qcow2: fix the macro QCOW_MAX_L1_SIZE's use
06d05fa qcow2: Allow creation with refcount order != 4
8a17b83 qcow2: Use symbolic macros in qcow2_amend_options
bd4b167 qcow2: refcount_order parameter for qcow2_create2
b72faf9 qcow2: Open images with refcount order != 4
0709c5a qcow2: Add refcount_bits to format-specific info
346a53d qcow2: Add two new fields to BDRVQcowState
f43e47d QemuOpts: Drop qemu_opt_set(), rename qemu_opt_set_err(), fix use
39101f2 QemuOpts: Convert qemu_opt_set_number() to Error, fix its use
c0191e7 block: Remove "growable" from BDS
e729fa6 block: fix off-by-one error in qcow and qcow2
9a29e18 block: update string sizes for filename,backing_file,exact_filename
^ the previous commit that touched backing file, I am guessing this is the one needs a fix(correct me if I am wrong)


6a69b96 qcow2: Respect bdrv_truncate() error
3b5e14c qcow2: Flushing the caches in qcow2_close may fail
ef81043 block: Omit bdrv_find_format for essential drivers
5f535a9 block: Make essential BlockDriver objects public
2ebafc8 qcow2: Fix header extension size check
7fb8da2 Open 2.3 development tree



^ and seems both the above 2 commits are merged in version 2.3 window,
so this bug is not exist on any internal qemu binary.
internal latest 2.2.0-8 fellowed by 2.3.0-1, and not any rc of 2.3.

Kevin,

1) could you pls have a look whether above comment correct ?

2) I've tried the test case introduced along with this bug fix, it's fine on below internel binaries:
qemu-kvm-rhev-2.2.0-8
qemu-kvm-rhev-2.3.0-1
qemu-kvm-rhev-2.3.0-9

[root@dhcp-11-50 qemu-iotests]# ./check -qcow2 130
QEMU          -- /home/xwei/git-repos/qemu-kvm-rhev7/tests/qemu-iotests/../../x86_64-softmmu/qemu-system-x86_64
QEMU_IMG      -- /usr/bin/qemu-img
QEMU_IO       -- /home/xwei/git-repos/qemu-kvm-rhev7/tests/qemu-iotests/../../qemu-io 
QEMU_NBD      -- /home/xwei/git-repos/qemu-kvm-rhev7/tests/qemu-iotests/../../qemu-nbd
IMGFMT        -- qcow2 (compat=1.1)
IMGPROTO      -- file
PLATFORM      -- Linux/x86_64 dhcp-11-50 3.10.0-276.el7.x86_64
TEST_DIR      -- /home/xwei/git-repos/qemu-kvm-rhev7/tests/qemu-iotests/scratch
SOCKET_SCM_HELPER -- /home/xwei/git-repos/qemu-kvm-rhev7/tests/qemu-iotests/socket_scm_helper

130 2s ...
Passed all 1 tests


is 2) sufficient to verify this bug ?


Thanks,
Xiaoqing.

Comment 7 Kevin Wolf 2015-07-07 12:17:14 UTC
(In reply to Xiaoqing Wei from comment #6)
> ^ and seems both the above 2 commits are merged in version 2.3 window,
> so this bug is not exist on any internal qemu binary.
> internal latest 2.2.0-8 fellowed by 2.3.0-1, and not any rc of 2.3.
> 
> Kevin,
> 
> 1) could you pls have a look whether above comment correct ?

This looks correct to me.
 
> 2) I've tried the test case introduced along with this bug fix, it's fine on
> below internel binaries:
> qemu-kvm-rhev-2.2.0-8
> qemu-kvm-rhev-2.3.0-1
> qemu-kvm-rhev-2.3.0-9
> 
> is 2) sufficient to verify this bug ?

Yes, it is. Thanks for testing.

Comment 8 Xiaoqing Wei 2015-07-08 03:01:43 UTC
(In reply to Kevin Wolf from comment #7)
> > 
> > is 2) sufficient to verify this bug ?
> 
> Yes, it is. Thanks for testing.


Thanks for confirm,
Moving to VERIFIED.

Comment 10 errata-xmlrpc 2015-12-04 16:33:19 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2546.html


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