All of lore.kernel.org
 help / color / mirror / Atom feed
From: "José Expósito" <jose.exposito89@gmail.com>
To: David Gow <davidgow@google.com>
Cc: "Sam Ravnborg" <sam@ravnborg.org>,
	"Naresh Kamboju" <naresh.kamboju@linaro.org>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	javierm@redhat.com, "Maíra Canal" <mairacanal@riseup.net>,
	"Maxime Ripard" <maxime@cerno.tech>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"Linux Kernel Functional Testing" <lkft@linaro.org>,
	kunit-dev@googlegroups.com
Subject: Re: [PATCH] drm: tests: Fix a buffer overflow in format_helper_test
Date: Wed, 19 Oct 2022 19:29:19 +0200	[thread overview]
Message-ID: <20221019172919.GA5336@elementary> (raw)
In-Reply-To: <20221019073239.3779180-1-davidgow@google.com>

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
> 

WARNING: multiple messages have this Message-ID (diff)
From: "José Expósito" <jose.exposito89@gmail.com>
To: David Gow <davidgow@google.com>
Cc: "David Airlie" <airlied@gmail.com>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"Maxime Ripard" <maxime@cerno.tech>,
	"Naresh Kamboju" <naresh.kamboju@linaro.org>,
	"Maíra Canal" <mairacanal@riseup.net>,
	dri-devel@lists.freedesktop.org,
	"Sam Ravnborg" <sam@ravnborg.org>,
	linux-kernel@vger.kernel.org, kunit-dev@googlegroups.com,
	"Linux Kernel Functional Testing" <lkft@linaro.org>,
	javierm@redhat.com
Subject: Re: [PATCH] drm: tests: Fix a buffer overflow in format_helper_test
Date: Wed, 19 Oct 2022 19:29:19 +0200	[thread overview]
Message-ID: <20221019172919.GA5336@elementary> (raw)
In-Reply-To: <20221019073239.3779180-1-davidgow@google.com>

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
> 

  parent reply	other threads:[~2022-10-19 17:29 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-19  7:32 [PATCH] drm: tests: Fix a buffer overflow in format_helper_test David Gow
2022-10-19  7:32 ` David Gow
2022-10-19 11:36 ` Maíra Canal
2022-10-19 11:36   ` Maíra Canal
2022-10-19 16:14   ` Javier Martinez Canillas
2022-10-19 16:14     ` Javier Martinez Canillas
2022-10-21  7:43   ` David Gow
2022-10-21  7:43     ` David Gow
2022-10-19 17:29 ` José Expósito [this message]
2022-10-19 17:29   ` José Expósito
2022-10-20  8:03   ` Javier Martinez Canillas
2022-10-20  8:03     ` Javier Martinez Canillas
2022-10-21  7:37     ` David Gow
2022-10-21  7:37       ` David Gow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221019172919.GA5336@elementary \
    --to=jose.exposito89@gmail.com \
    --cc=davidgow@google.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=javierm@redhat.com \
    --cc=kunit-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkft@linaro.org \
    --cc=mairacanal@riseup.net \
    --cc=maxime@cerno.tech \
    --cc=naresh.kamboju@linaro.org \
    --cc=sam@ravnborg.org \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.