drm: tests: Fix a buffer overflow in format_helper_test

  The xrgb2101010 format conversion test (unlike for other formats) does
an endianness conversion on the results. However, it always converts
TEST_BUF_SIZE 32-bit integers, which results in reading from (and
writing to) more memory than in present in the result buffer. Instead,
use the buffer size, divided by sizeof(u32).

The issue could be reproduced with KASAN:
./tools/testing/kunit/kunit.py run --kunitconfig drivers/gpu/drm/tests \
	--kconfig_add CONFIG_KASAN=y --kconfig_add CONFIG_KASAN_VMALLOC=y \
	--kconfig_add CONFIG_KASAN_KUNIT_TEST=y \
	drm_format_helper_test.*xrgb2101010

Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
Fixes: 453114319699 ("drm/format-helper: Add KUnit tests for drm_fb_xrgb8888_to_xrgb2101010()")
Signed-off-by: David Gow <davidgow@google.com>
---

This is a fix for the issue reported here:
https://lore.kernel.org/dri-devel/CA+G9fYsuc9G+RO81E=vHMqxYStsmLURLdOB0NF26kJ1=K8pRZA@mail.gmail.com/

Note that it may conflict with the KUNIT_EXPECT_MEMEQ() series here:
https://lore.kernel.org/linux-kselftest/20221018190541.189780-1-mairacanal@riseup.net/

Cheers,
-- David

---
 drivers/gpu/drm/tests/drm_format_helper_test.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
  

[cc Javier]

Hi David,

On 10/19/22 04:32, David Gow wrote:
> The xrgb2101010 format conversion test (unlike for other formats) does
> an endianness conversion on the results. However, it always converts
> TEST_BUF_SIZE 32-bit integers, which results in reading from (and
> writing to) more memory than in present in the result buffer. Instead,
> use the buffer size, divided by sizeof(u32).
> 
> The issue could be reproduced with KASAN:
> ./tools/testing/kunit/kunit.py run --kunitconfig drivers/gpu/drm/tests \
> 	--kconfig_add CONFIG_KASAN=y --kconfig_add CONFIG_KASAN_VMALLOC=y \
> 	--kconfig_add CONFIG_KASAN_KUNIT_TEST=y \
> 	drm_format_helper_test.*xrgb2101010
> 
> Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
> Fixes: 453114319699 ("drm/format-helper: Add KUnit tests for drm_fb_xrgb8888_to_xrgb2101010()")
> Signed-off-by: David Gow <davidgow@google.com>

Reviewed-by: Maíra Canal <mairacanal@riseup.net>

> ---
> 
> This is a fix for the issue reported here:
> https://lore.kernel.org/dri-devel/CA+G9fYsuc9G+RO81E=vHMqxYStsmLURLdOB0NF26kJ1=K8pRZA@mail.gmail.com/
> 
> Note that it may conflict with the KUNIT_EXPECT_MEMEQ() series here:
> https://lore.kernel.org/linux-kselftest/20221018190541.189780-1-mairacanal@riseup.net/

I believe this patch will go to the drm-misc-fixes tree, so I can rebase
the series (and address the format issues) as this patch hits mainline.

Best Regards,
- Maíra Canal

> 
> Cheers,
> -- David
> 
> ---
>  drivers/gpu/drm/tests/drm_format_helper_test.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c b/drivers/gpu/drm/tests/drm_format_helper_test.c
> index 8d86c250c2ec..2191e57f2297 100644
> --- a/drivers/gpu/drm/tests/drm_format_helper_test.c
> +++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
> @@ -438,7 +438,7 @@ static void drm_test_fb_xrgb8888_to_xrgb2101010(struct kunit *test)
>  	iosys_map_set_vaddr(&src, xrgb8888);
>  
>  	drm_fb_xrgb8888_to_xrgb2101010(&dst, &result->dst_pitch, &src, &fb, &params->clip);
> -	buf = le32buf_to_cpu(test, buf, TEST_BUF_SIZE);
> +	buf = le32buf_to_cpu(test, buf, dst_size / sizeof(u32));
>  	KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected, dst_size), 0);
>  }
>
  

On 10/19/22 13:36, Maíra Canal wrote:
> [cc Javier]
> 
> Hi David,
> 
> On 10/19/22 04:32, David Gow wrote:
>> The xrgb2101010 format conversion test (unlike for other formats) does
>> an endianness conversion on the results. However, it always converts
>> TEST_BUF_SIZE 32-bit integers, which results in reading from (and
>> writing to) more memory than in present in the result buffer. Instead,
>> use the buffer size, divided by sizeof(u32).
>>
>> The issue could be reproduced with KASAN:
>> ./tools/testing/kunit/kunit.py run --kunitconfig drivers/gpu/drm/tests \
>> 	--kconfig_add CONFIG_KASAN=y --kconfig_add CONFIG_KASAN_VMALLOC=y \
>> 	--kconfig_add CONFIG_KASAN_KUNIT_TEST=y \
>> 	drm_format_helper_test.*xrgb2101010
>>
>> Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
>> Fixes: 453114319699 ("drm/format-helper: Add KUnit tests for drm_fb_xrgb8888_to_xrgb2101010()")
>> Signed-off-by: David Gow <davidgow@google.com>
> 
> Reviewed-by: Maíra Canal <mairacanal@riseup.net>
>

The fix makes sense to me as well,

Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>

>> ---
>>
>> This is a fix for the issue reported here:
>> https://lore.kernel.org/dri-devel/CA+G9fYsuc9G+RO81E=vHMqxYStsmLURLdOB0NF26kJ1=K8pRZA@mail.gmail.com/
>>
>> Note that it may conflict with the KUNIT_EXPECT_MEMEQ() series here:
>> https://lore.kernel.org/linux-kselftest/20221018190541.189780-1-mairacanal@riseup.net/
> 
> I believe this patch will go to the drm-misc-fixes tree, so I can rebase
> the series (and address the format issues) as this patch hits mainline.
> 

Awesome. I assume you are pushing to drm-misc-fixes then?

Thanks a lot David and Maíra for taking care of this!
  

On Wed, Oct 19, 2022 at 03:32:40PM +0800, David Gow wrote:
> The xrgb2101010 format conversion test (unlike for other formats) does
> an endianness conversion on the results. However, it always converts
> TEST_BUF_SIZE 32-bit integers, which results in reading from (and
> writing to) more memory than in present in the result buffer. Instead,
> use the buffer size, divided by sizeof(u32).
> 
> The issue could be reproduced with KASAN:
> ./tools/testing/kunit/kunit.py run --kunitconfig drivers/gpu/drm/tests \
> 	--kconfig_add CONFIG_KASAN=y --kconfig_add CONFIG_KASAN_VMALLOC=y \
> 	--kconfig_add CONFIG_KASAN_KUNIT_TEST=y \
> 	drm_format_helper_test.*xrgb2101010
> 
> Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
> Fixes: 453114319699 ("drm/format-helper: Add KUnit tests for drm_fb_xrgb8888_to_xrgb2101010()")
> Signed-off-by: David Gow <davidgow@google.com>
> ---
> 
> This is a fix for the issue reported here:
> https://lore.kernel.org/dri-devel/CA+G9fYsuc9G+RO81E=vHMqxYStsmLURLdOB0NF26kJ1=K8pRZA@mail.gmail.com/
> 
> Note that it may conflict with the KUNIT_EXPECT_MEMEQ() series here:
> https://lore.kernel.org/linux-kselftest/20221018190541.189780-1-mairacanal@riseup.net/
> 
> Cheers,
> -- David
> 
> ---
>  drivers/gpu/drm/tests/drm_format_helper_test.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c b/drivers/gpu/drm/tests/drm_format_helper_test.c
> index 8d86c250c2ec..2191e57f2297 100644
> --- a/drivers/gpu/drm/tests/drm_format_helper_test.c
> +++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
> @@ -438,7 +438,7 @@ static void drm_test_fb_xrgb8888_to_xrgb2101010(struct kunit *test)
>  	iosys_map_set_vaddr(&src, xrgb8888);
>  
>  	drm_fb_xrgb8888_to_xrgb2101010(&dst, &result->dst_pitch, &src, &fb, &params->clip);
> -	buf = le32buf_to_cpu(test, buf, TEST_BUF_SIZE);
> +	buf = le32buf_to_cpu(test, buf, dst_size / sizeof(u32));
>  	KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected, dst_size), 0);
>  }

Thanks a lot for fixing this bug David, I just tested it and
worked as expected.

Do you think that we should update the other calls to
le32buf_to_cpu() to follow a similar approach?

Regardless of a possible follow up patch:
Reviewed-by: José Expósito <jose.exposito89@gmail.com>

Jose

>  
> -- 
> 2.38.0.413.g74048e4d9e-goog
>
  

On 10/19/22 19:29, José Expósito wrote:

[...]

>>  drivers/gpu/drm/tests/drm_format_helper_test.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c b/drivers/gpu/drm/tests/drm_format_helper_test.c
>> index 8d86c250c2ec..2191e57f2297 100644
>> --- a/drivers/gpu/drm/tests/drm_format_helper_test.c
>> +++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
>> @@ -438,7 +438,7 @@ static void drm_test_fb_xrgb8888_to_xrgb2101010(struct kunit *test)
>>  	iosys_map_set_vaddr(&src, xrgb8888);
>>  
>>  	drm_fb_xrgb8888_to_xrgb2101010(&dst, &result->dst_pitch, &src, &fb, &params->clip);
>> -	buf = le32buf_to_cpu(test, buf, TEST_BUF_SIZE);
>> +	buf = le32buf_to_cpu(test, buf, dst_size / sizeof(u32));
>>  	KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected, dst_size), 0);
>>  }
> 
> Thanks a lot for fixing this bug David, I just tested it and
> worked as expected.
>

I've pushed this to drm-misc (drm-misc-fixes) now. Thanks!
 
> Do you think that we should update the other calls to
> le32buf_to_cpu() to follow a similar approach?
>

Feel free to post follow-up patches if you think that other changes are needed.
  

On Thu, Oct 20, 2022 at 4:03 PM Javier Martinez Canillas
<javierm@redhat.com> wrote:
>
> On 10/19/22 19:29, José Expósito wrote:
>
> [...]
>
> >>  drivers/gpu/drm/tests/drm_format_helper_test.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c b/drivers/gpu/drm/tests/drm_format_helper_test.c
> >> index 8d86c250c2ec..2191e57f2297 100644
> >> --- a/drivers/gpu/drm/tests/drm_format_helper_test.c
> >> +++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
> >> @@ -438,7 +438,7 @@ static void drm_test_fb_xrgb8888_to_xrgb2101010(struct kunit *test)
> >>      iosys_map_set_vaddr(&src, xrgb8888);
> >>
> >>      drm_fb_xrgb8888_to_xrgb2101010(&dst, &result->dst_pitch, &src, &fb, &params->clip);
> >> -    buf = le32buf_to_cpu(test, buf, TEST_BUF_SIZE);
> >> +    buf = le32buf_to_cpu(test, buf, dst_size / sizeof(u32));
> >>      KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected, dst_size), 0);
> >>  }
> >
> > Thanks a lot for fixing this bug David, I just tested it and
> > worked as expected.
> >
>
> I've pushed this to drm-misc (drm-misc-fixes) now. Thanks!
>

Thanks very much!

> > Do you think that we should update the other calls to
> > le32buf_to_cpu() to follow a similar approach?
> >
>
> Feel free to post follow-up patches if you think that other changes are needed.
>

I _think_ this should be the only actually necessary change. Maybe
there's some cleanup of the way TEST_BUF_SIZE is used, or the sparse
annotations for endianness, but I'd need to look into exactly what the
various drm_format definitions are in more detail to know for sure.

Cheers,
-- David
  

On Wed, Oct 19, 2022 at 7:36 PM Maíra Canal <mairacanal@riseup.net> wrote:
>
> [cc Javier]
>
> Hi David,
>
> On 10/19/22 04:32, David Gow wrote:
> > The xrgb2101010 format conversion test (unlike for other formats) does
> > an endianness conversion on the results. However, it always converts
> > TEST_BUF_SIZE 32-bit integers, which results in reading from (and
> > writing to) more memory than in present in the result buffer. Instead,
> > use the buffer size, divided by sizeof(u32).
> >
> > The issue could be reproduced with KASAN:
> > ./tools/testing/kunit/kunit.py run --kunitconfig drivers/gpu/drm/tests \
> >       --kconfig_add CONFIG_KASAN=y --kconfig_add CONFIG_KASAN_VMALLOC=y \
> >       --kconfig_add CONFIG_KASAN_KUNIT_TEST=y \
> >       drm_format_helper_test.*xrgb2101010
> >
> > Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
> > Fixes: 453114319699 ("drm/format-helper: Add KUnit tests for drm_fb_xrgb8888_to_xrgb2101010()")
> > Signed-off-by: David Gow <davidgow@google.com>
>
> Reviewed-by: Maíra Canal <mairacanal@riseup.net>
>

Thanks a lot, Maíra!

> > ---
> >
> > This is a fix for the issue reported here:
> > https://lore.kernel.org/dri-devel/CA+G9fYsuc9G+RO81E=vHMqxYStsmLURLdOB0NF26kJ1=K8pRZA@mail.gmail.com/
> >
> > Note that it may conflict with the KUNIT_EXPECT_MEMEQ() series here:
> > https://lore.kernel.org/linux-kselftest/20221018190541.189780-1-mairacanal@riseup.net/
>
> I believe this patch will go to the drm-misc-fixes tree, so I can rebase
> the series (and address the format issues) as this patch hits mainline.

We're probably going to want the KUNIT_EXPECT_MEMEQ() merged in the
kselftest/kunit tree reasonably soon, as there's a few things we'd
like to use it for that we're hoping to get into 6.2.

Given that any conflict is only likely to affect context lines, it
hopefully won't be too much of a problem to resolve it when everything
gets merged, though.

Cheers,
-- David