From: Kevin Wolf <kwolf@redhat.com>
To: Peter Lieven <pl@kamp.de>
Cc: codyprime@gmail.com, Jan-Hendrik Frintrop <jhf@kamp.de>,
qemu-devel@nongnu.org, qemu-block@nongnu.org, mreitz@redhat.com
Subject: Re: [Qemu-devel] [PATCH] block/vhdx: add check for truncated image files
Date: Mon, 2 Sep 2019 15:07:01 +0200 [thread overview]
Message-ID: <20190902130701.GE13140@localhost.localdomain> (raw)
In-Reply-To: <20190829133615.29873-1-pl@kamp.de>
Am 29.08.2019 um 15:36 hat Peter Lieven geschrieben:
> qemu is currently not able to detect truncated vhdx image files.
> Add a basic check if all allocated blocks are reachable to vhdx_co_check.
>
> Signed-off-by: Jan-Hendrik Frintrop <jhf@kamp.de>
> Signed-off-by: Peter Lieven <pl@kamp.de>
> ---
> block/vhdx.c | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/block/vhdx.c b/block/vhdx.c
> index 6a09d0a55c..4382b1375d 100644
> --- a/block/vhdx.c
> +++ b/block/vhdx.c
> @@ -2068,10 +2068,29 @@ static int coroutine_fn vhdx_co_check(BlockDriverState *bs,
> BdrvCheckMode fix)
> {
> BDRVVHDXState *s = bs->opaque;
> + VHDXSectorInfo sinfo;
> + int64_t file_size = bdrv_get_allocated_file_size(bs);
Don't you mean bdrv_getlength()?
bdrv_get_allocated_file_size() is only the allocated size, i.e. without
holes. So a higher offset may actually be present.
> + int64_t sector_num;
>
> if (s->log_replayed_on_open) {
> result->corruptions_fixed++;
> }
> +
> + for (sector_num = 0; sector_num < bs->total_sectors;
> + sector_num += s->block_size / BDRV_SECTOR_SIZE) {
> + int nb_sectors = MIN(bs->total_sectors - sector_num,
> + s->block_size / BDRV_SECTOR_SIZE);
> + vhdx_block_translate(s, sector_num, nb_sectors, &sinfo);
> + if ((s->bat[sinfo.bat_idx] & VHDX_BAT_STATE_BIT_MASK) ==
> + PAYLOAD_BLOCK_FULLY_PRESENT) {
> + if (sinfo.file_offset +
> + sinfo.sectors_avail * BDRV_SECTOR_SIZE > file_size) {
Do we need to protect against integer overflows here? I think
sinfo.file_offset comes directly from the image file and might be
corrupted.
Or has it already been check somewhere?
> + /* block is past the end of file, image has been truncated. */
> + result->corruptions++;
I think we should print an error message like other formats do, so that
the user knows which kind of corruption 'qemu-img check' found (include
the guest and host offset of the invalid block).
> + }
> + }
> + }
> +
> return 0;
> }
Kevin
next prev parent reply other threads:[~2019-09-02 13:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-29 13:36 [Qemu-devel] [PATCH] block/vhdx: add check for truncated image files Peter Lieven
2019-09-02 13:07 ` Kevin Wolf [this message]
2019-09-02 13:15 ` Peter Lieven
2019-09-02 13:46 ` Kevin Wolf
2019-09-02 14:17 ` Peter Lieven
2019-09-02 14:31 ` Kevin Wolf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190902130701.GE13140@localhost.localdomain \
--to=kwolf@redhat.com \
--cc=codyprime@gmail.com \
--cc=jhf@kamp.de \
--cc=mreitz@redhat.com \
--cc=pl@kamp.de \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).