Re: qemu-img.c possibly overflowing shifts by BDRV_SECTOR_BITS

[Peter Maydell <peter.maydell@linaro.org>]

On Wed, 10 Nov 2021 at 11:36, Kevin Wolf <kwolf@redhat.com> wrote:
>
> Am 09.11.2021 um 20:07 hat Peter Maydell geschrieben:
> > Hi; Coverity is complaining about some of the places in qemu-img.c
> > where it takes a 32-bit variable and shifts it left by BDRV_SECTOR_BITS
> > to convert a sector count to a byte count, because it's doing the
> > shift in 32-bits rather than 64 and so Coverity thinks there might
> > be overflow (CID 1465221, 1465219). Is it right and we need extra
> > casts to force the shift to be done in 64 bits, or is there some
> > constraint that means we know the sector counts are always small
> > enough that the byte count is 2GB or less ?
>
> These are false positives. n is limited to BDRV_REQUEST_MAX_SECTORS
> already when it starts out in convert_iteration_sectors() (which is
> enough to make the calculation safe), but for the specific code path, I
> think it's even guaranteed to be further limited to s->buf_sectors which
> is 16 MB at most (MAX_BUF_SECTORS in qemu-img.c).

Thanks. I've marked them as false-positives in the coverity UI.

-- PMM