qemu-img.c possibly overflowing shifts by BDRV_SECTOR_BITS

qemu-img.c possibly overflowing shifts by BDRV_SECTOR_BITS

[Peter Maydell]

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 ?

thanks
-- PMM

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

[Kevin Wolf]

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).

Kevin

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

[Peter Maydell]

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