[Mesa-dev] [PATCH] llvmpipe: fix overflow bug in total texture size computation
Roland Scheidegger
sroland at vmware.com
Wed Sep 19 15:47:38 PDT 2012
Good catch.
I'm not sure though using size_t casts (and size_t sized total_value)
is good enough since this could also be hit on archs using 32bit size_t?
Though i guess using 64bit arithmetic on 32bit would be sort of slow...
Roland
Am 19.09.2012 21:30, schrieb Brian Paul:
> Add size_t casts when multiplying slice size by number of slices to
> avoid 32-bit uint overflow. This bug has been here for a long time.
> But before the recent proxy texture changes, core Mesa was detecting
> that the texture was too large and we never got this far.
>
> Fixes https://bugs.freedesktop.org/show_bug.cgi?id=55117
> ---
> src/gallium/drivers/llvmpipe/lp_texture.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/src/gallium/drivers/llvmpipe/lp_texture.c b/src/gallium/drivers/llvmpipe/lp_texture.c
> index c0a612c..0aa1299 100644
> --- a/src/gallium/drivers/llvmpipe/lp_texture.c
> +++ b/src/gallium/drivers/llvmpipe/lp_texture.c
> @@ -172,7 +172,9 @@ llvmpipe_texture_layout(struct llvmpipe_screen *screen,
> }
> }
>
> - total_size += lpr->num_slices_faces[level] * lpr->img_stride[level];
> + total_size += (size_t) lpr->num_slices_faces[level]
> + * (size_t) lpr->img_stride[level];
> +
> if (total_size > LP_MAX_TEXTURE_SIZE) {
> goto fail;
> }
>
More information about the mesa-dev
mailing list