On Jun 3, 2016 8:43 AM, <robert.f...@collabora.com> wrote:
>
> From: Robert Foss <robert.f...@collabora.com>
>
> Avoid out of bounds access of the array 'src'.
>
> 'src' is passed along:
> nir_eval_const_opcode()
> evaluate_bitfield_insert()
>
> In evaluate_bitfield_insert() an access to src[3] is made
> if bit_size==32 wich it always will be due to the
> assert(bit_size == 32) on spirv_to_nir.c:1045.
>
> Since 'src' is of length 3, this is out of bounds.
>
> Coverity id: 1358582
>
> Signed-off-by: Robert Foss <robert.f...@collabora.com>
> ---
> src/compiler/spirv/spirv_to_nir.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/compiler/spirv/spirv_to_nir.c
b/src/compiler/spirv/spirv_to_nir.c
> index 99514b4..46ede6a 100644
> --- a/src/compiler/spirv/spirv_to_nir.c
> +++ b/src/compiler/spirv/spirv_to_nir.c
> @@ -1035,7 +1035,7 @@ vtn_handle_constant(struct vtn_builder *b, SpvOp
opcode,
> unsigned bit_size =
> glsl_get_bit_size(glsl_get_base_type(val->const_type));
>
> - nir_const_value src[3];
> + nir_const_value src[4];
None of the Opcode's evaluated as specialization constants have four
sources so this will never be a problem. Hence the assert on the next
line. I think we should just mark this as a false positive.
> assert(count <= 7);
> for (unsigned i = 0; i < count - 4; i++) {
> nir_constant *c =
> --
> 2.7.4
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
