diff options
author | Kevin Wolf <kwolf@redhat.com> | 2025-03-18 21:11:43 +0100 |
---|---|---|
committer | Kevin Wolf <kwolf@redhat.com> | 2025-04-08 12:13:17 +0200 |
commit | 8e4ffb4ef434af3667a90276d75d301b582bf78c (patch) | |
tree | 09ccf462bd88a7edb6f041de2aaa302c57881192 /rust/qemu-api/src | |
parent | 6b36a578316e3b14a53ae7699571d01b00fc2f8a (diff) | |
download | qemu-8e4ffb4ef434af3667a90276d75d301b582bf78c.zip qemu-8e4ffb4ef434af3667a90276d75d301b582bf78c.tar.gz qemu-8e4ffb4ef434af3667a90276d75d301b582bf78c.tar.bz2 |
qcow2: Don't crash qemu-img info with missing crypto header
qcow2_refresh_limits() assumes that s->crypto is non-NULL whenever
bs->encrypted is true. This is actually not the case: qcow2_do_open()
allows to open an image with a missing crypto header for BDRV_O_NO_IO,
and then bs->encrypted is true, but s->crypto is still NULL.
It doesn't make sense to open an invalid image, so remove the exception
for BDRV_O_NO_IO. This catches the problem early and any code that makes
the same assumption is safe now.
At the same time, in the name of defensive programming, we shouldn't
make the assumption in the first place. Let qcow2_refresh_limits() check
s->crypto rather than bs->encrypted. If s->crypto is NULL, it also can't
make any requirement on request alignment.
Finally, start a qcow2-encryption test case that only serves as a
regression test for this crash for now.
Reported-by: Leonid Reviakin <L.reviakin@fobos-nt.ru>
Reported-by: Denis Rastyogin <gerben@altlinux.org>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20250318201143.70657-1-kwolf@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Diffstat (limited to 'rust/qemu-api/src')
0 files changed, 0 insertions, 0 deletions