From: "Denis V. Lunev" <den@virtuozzo.com>
To: Kevin Wolf <kwolf@redhat.com>, Dmitry Frolov <frolov@swemel.ru>
Cc: stefanha@redhat.com, den@openvz.org, sdl.qemu@linuxtesting.org,
qemu-devel@nongnu.org, qemu-block@nongnu.org
Subject: Re: [PATCH] block: fix possible int overflow
Date: Fri, 8 Nov 2024 12:36:15 +0100 [thread overview]
Message-ID: <7894af7b-d0e4-41f4-8c6e-f4f6de5f25aa@virtuozzo.com> (raw)
In-Reply-To: <Zys8tLcKjADMtkqn@redhat.com>
On 11/6/24 10:53, Kevin Wolf wrote:
> [ Cc: qemu-block ]
>
> Am 06.11.2024 um 09:04 hat Dmitry Frolov geschrieben:
>> The sum "cluster_index + count" may overflow uint32_t.
>>
>> Found by Linux Verification Center (linuxtesting.org) with SVACE.
>>
>> Signed-off-by: Dmitry Frolov <frolov@swemel.ru>
> Thanks, applied to the block branch.
>
> While trying to check if this can be triggered in practice, I found this
> line in parallels_fill_used_bitmap():
>
> s->used_bmap_size = DIV_ROUND_UP(payload_bytes, s->cluster_size);
>
> s->used_bmap_size is unsigned long, payload_bytes is the int64_t result
> of bdrv_getlength() for the image file, which could certainly be made
> more than 4 GB * cluster_size. I think we need an overflow check there,
> too.
>
> When allocate_clusters() calculates new_usedsize, it doesn't seem to
> consider the overflow case either.
>
> Denis, can you take a look?
>
> Kevin
>
We definitely have more places inside the code and I'll take a look.
Speaking about this particular change - this will not work. In general
we should signal corruption when the cluster number is overflowed.
This data would not be accessible due to format restrictions.
Den
prev parent reply other threads:[~2024-11-08 11:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-06 8:04 [PATCH] block: fix possible int overflow Dmitry Frolov
2024-11-06 9:53 ` Kevin Wolf
2024-11-06 15:45 ` Denis V. Lunev
2024-11-06 16:00 ` Kevin Wolf
2024-11-08 11:32 ` Denis V. Lunev
2024-11-08 11:36 ` Denis V. Lunev [this message]
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=7894af7b-d0e4-41f4-8c6e-f4f6de5f25aa@virtuozzo.com \
--to=den@virtuozzo.com \
--cc=den@openvz.org \
--cc=frolov@swemel.ru \
--cc=kwolf@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=sdl.qemu@linuxtesting.org \
--cc=stefanha@redhat.com \
/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).