[PATCH] kcsan: test: Adjust "expect" allocation type for kmalloc_obj

1 view
Skip to first unread message

Kees Cook

unread,
Feb 23, 2026, 5:22:34 PM (5 days ago) Feb 23
to Marco Elver, Kees Cook, Nathan Chancellor, Dmitry Vyukov, kasa...@googlegroups.com, linux-...@vger.kernel.org, linux-h...@vger.kernel.org
Instead of depending on the implicit case between a pointer to pointers
and pointer to arrays, use the assigned variable type for the allocation
type so they correctly match. Solves the following build error:

../kernel/kcsan/kcsan_test.c: In function '__report_matches':
../kernel/kcsan/kcsan_test.c:171:16: error: assignment to 'char (*)[512]' from incompatible pointer type 'char (*)[3][512]'
[-Wincompatible-pointer-types]
171 | expect = kmalloc_obj(observed.lines);
| ^

Tested with:

$ ./tools/testing/kunit/kunit.py run \
--kconfig_add CONFIG_DEBUG_KERNEL=y \
--kconfig_add CONFIG_KCSAN=y \
--kconfig_add CONFIG_KCSAN_KUNIT_TEST=y \
--arch=x86_64 --qemu_args '-smp 2' kcsan

Reported-by: Nathan Chancellor <nat...@kernel.org>
Fixes: 69050f8d6d07 ("treewide: Replace kmalloc with kmalloc_obj for non-scalar types")
Signed-off-by: Kees Cook <ke...@kernel.org>
---
Cc: Marco Elver <el...@google.com>
Cc: Dmitry Vyukov <dvy...@google.com>
Cc: <kasa...@googlegroups.com>
---
kernel/kcsan/kcsan_test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/kcsan/kcsan_test.c b/kernel/kcsan/kcsan_test.c
index 79e655ea4ca1..056fa859ad9a 100644
--- a/kernel/kcsan/kcsan_test.c
+++ b/kernel/kcsan/kcsan_test.c
@@ -168,7 +168,7 @@ static bool __report_matches(const struct expect_report *r)
if (!report_available())
return false;

- expect = kmalloc_obj(observed.lines);
+ expect = kmalloc_obj(*expect);
if (WARN_ON(!expect))
return false;

--
2.34.1

Marco Elver

unread,
Feb 24, 2026, 5:10:24 AM (4 days ago) Feb 24
to Kees Cook, Nathan Chancellor, Dmitry Vyukov, kasa...@googlegroups.com, linux-...@vger.kernel.org, linux-h...@vger.kernel.org
This is wrong. Instead of allocating 3x512 bytes it's now only
allocating 512 bytes, so we get OOB below with this change. 'expect'
is a pointer to a 3-dimensional array of 512-char arrays (matching
observed.lines).

Kees Cook

unread,
Feb 24, 2026, 4:48:54 PM (4 days ago) Feb 24
to Marco Elver, Nathan Chancellor, Dmitry Vyukov, kasa...@googlegroups.com, linux-...@vger.kernel.org, linux-h...@vger.kernel.org
Why did running the kunit test not trip over this? :(

Hmpf, getting arrays allocated without an explicit cast seems to be
impossible. How about this:


diff --git a/kernel/kcsan/kcsan_test.c b/kernel/kcsan/kcsan_test.c
index 056fa859ad9a..ae758150ccb9 100644
--- a/kernel/kcsan/kcsan_test.c
+++ b/kernel/kcsan/kcsan_test.c
@@ -168,7 +168,7 @@ static bool __report_matches(const struct expect_report *r)
if (!report_available())
return false;

- expect = kmalloc_obj(*expect);
+ expect = (typeof(expect))kmalloc_obj(observed.lines);
if (WARN_ON(!expect))
return false;




--
Kees Cook

Marco Elver

unread,
Feb 24, 2026, 5:40:24 PM (4 days ago) Feb 24
to Kees Cook, Nathan Chancellor, Dmitry Vyukov, kasa...@googlegroups.com, linux-...@vger.kernel.org, linux-h...@vger.kernel.org
That works - or why not revert it back to normal kmalloc? There's
marginal benefit for kmalloc_obj() in this case, and this really is
just a bunch of char buffers - not a complex object. If there's still
a benefit to be had from kmalloc_obj() here, I'm fine with the typeof
cast.

Thanks,
-- Marco

Kees Cook

unread,
Feb 24, 2026, 5:41:10 PM (4 days ago) Feb 24
to Marco Elver, Nathan Chancellor, Dmitry Vyukov, kasa...@googlegroups.com, linux-...@vger.kernel.org, linux-h...@vger.kernel.org
Or:

expect = kmalloc_objs(*observed.lines, ARRAY_SIZE(observed.lines));

I think the quoted cast is probably better...

--
Kees Cook

Marco Elver

unread,
Feb 24, 2026, 5:44:01 PM (4 days ago) Feb 24
to Kees Cook, Nathan Chancellor, Dmitry Vyukov, kasa...@googlegroups.com, linux-...@vger.kernel.org, linux-h...@vger.kernel.org
The cast is easier to read (no indirection needed to understand it's
just allocating same size as observed.lines).

Kees Cook

unread,
Feb 24, 2026, 6:24:44 PM (4 days ago) Feb 24
to Marco Elver, Kees Cook, Nathan Chancellor, Dmitry Vyukov, kasa...@googlegroups.com, linux-...@vger.kernel.org, linux-h...@vger.kernel.org
The call to kmalloc_obj(observed.lines) returns "char (*)[3][512]",
a pointer to the whole 2D array. But "expect" wants to be "char (*)[512]",
the decayed pointer type, as if it were observed.lines itself (though
without the "3" bounds). This produces the following build error:

../kernel/kcsan/kcsan_test.c: In function '__report_matches':
../kernel/kcsan/kcsan_test.c:171:16: error: assignment to 'char (*)[512]' from incompatible pointer type 'char (*)[3][512]'
[-Wincompatible-pointer-types]
171 | expect = kmalloc_obj(observed.lines);
| ^

Instead of changing the "expect" type to "char (*)[3][512]" and
requiring a dereference at each use (e.g. "(expect*)[0]"), just
explicitly cast the return to the desired type.

Tested with:

$ ./tools/testing/kunit/kunit.py run \
--kconfig_add CONFIG_DEBUG_KERNEL=y \
--kconfig_add CONFIG_KCSAN=y \
--kconfig_add CONFIG_KCSAN_KUNIT_TEST=y \
--arch=x86_64 --qemu_args '-smp 2' kcsan

Reported-by: Nathan Chancellor <nat...@kernel.org>
Fixes: 69050f8d6d07 ("treewide: Replace kmalloc with kmalloc_obj for non-scalar types")
Signed-off-by: Kees Cook <ke...@kernel.org>
---
Cc: Marco Elver <el...@google.com>
Cc: Dmitry Vyukov <dvy...@google.com>
Cc: <kasa...@googlegroups.com>
---
kernel/kcsan/kcsan_test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/kcsan/kcsan_test.c b/kernel/kcsan/kcsan_test.c
index 79e655ea4ca1..ae758150ccb9 100644
--- a/kernel/kcsan/kcsan_test.c
+++ b/kernel/kcsan/kcsan_test.c
@@ -168,7 +168,7 @@ static bool __report_matches(const struct expect_report *r)
if (!report_available())
return false;

- expect = kmalloc_obj(observed.lines);
+ expect = (typeof(expect))kmalloc_obj(observed.lines);
if (WARN_ON(!expect))
return false;

--
2.34.1

Kees Cook

unread,
Feb 24, 2026, 6:28:05 PM (4 days ago) Feb 24
to Marco Elver, Nathan Chancellor, Dmitry Vyukov, kasa...@googlegroups.com, linux-...@vger.kernel.org, linux-h...@vger.kernel.org
Honestly... it's because I can't figure out how to make a exclusion for
this (nor how to get multidimensional array types) in Coccinelle to
avoid this case. (So re-running the conversion script will keep trying
to change this case.) And it's the only place in the kernel doing this
kind of thing. :P

I've sent v2 with the cast and a better commit log describing what's
happening.

--
Kees Cook

Marco Elver

unread,
Feb 24, 2026, 9:56:07 PM (4 days ago) Feb 24
to Kees Cook, Nathan Chancellor, Dmitry Vyukov, kasa...@googlegroups.com, linux-...@vger.kernel.org, linux-h...@vger.kernel.org
On Wed, 25 Feb 2026 at 00:24, Kees Cook <ke...@kernel.org> wrote:
>
> The call to kmalloc_obj(observed.lines) returns "char (*)[3][512]",
> a pointer to the whole 2D array. But "expect" wants to be "char (*)[512]",
> the decayed pointer type, as if it were observed.lines itself (though
> without the "3" bounds). This produces the following build error:
>
> ../kernel/kcsan/kcsan_test.c: In function '__report_matches':
> ../kernel/kcsan/kcsan_test.c:171:16: error: assignment to 'char (*)[512]' from incompatible pointer type 'char (*)[3][512]'
> [-Wincompatible-pointer-types]
> 171 | expect = kmalloc_obj(observed.lines);
> | ^
>
> Instead of changing the "expect" type to "char (*)[3][512]" and
> requiring a dereference at each use (e.g. "(expect*)[0]"), just
> explicitly cast the return to the desired type.
>
> Tested with:
>
> $ ./tools/testing/kunit/kunit.py run \
> --kconfig_add CONFIG_DEBUG_KERNEL=y \
> --kconfig_add CONFIG_KCSAN=y \
> --kconfig_add CONFIG_KCSAN_KUNIT_TEST=y \
> --arch=x86_64 --qemu_args '-smp 2' kcsan
>
> Reported-by: Nathan Chancellor <nat...@kernel.org>
> Fixes: 69050f8d6d07 ("treewide: Replace kmalloc with kmalloc_obj for non-scalar types")
> Signed-off-by: Kees Cook <ke...@kernel.org>

Reviewed-by: Marco Elver <el...@google.com>

I'm assuming you'll take it through your tree.

Thanks!
Reply all
Reply to author
Forward
0 new messages