From: SJ Park <sj@kernel.org>
To: sashiko-bot@kernel.org
Cc: SJ Park <sj@kernel.org>, damon@lists.linux.dev
Subject: Re: [PATCH v1.1 2/6] mm/damon/tests/core-kunit: catch test failure in test_merge_regions_of()
Date: Tue, 14 Jul 2026 20:31:56 -0700 [thread overview]
Message-ID: <20260715033157.109327-1-sj@kernel.org> (raw)
In-Reply-To: <20260715031908.683501F000E9@smtp.kernel.org>
On Wed, 15 Jul 2026 03:19:07 +0000 sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>
> Pre-existing issues:
> - [Medium] The patch correctly identifies that `KUNIT_EXPECT_EQ()` does not abort test execution on failure, which causes undefined behavior in subsequent code if the test expectation is not met. However, it leaves the exact same anti-pattern unfixed in several other test helper functions within the DAMON test suite. This can lead to out-of-bounds (OOB) array reads, NULL pointer dereferences, and slab corruption when test failures occur.
> --
>
> --- Patch [2]: [PATCH v1.1 2/6] mm/damon/tests/core-kunit: catch test failure in test_merge_regions_of() ---
> commit ce2690fbbc97573d0a06744653f652063e18c91b
> Author: SJ Park <sj@kernel.org>
> Date: Wed Jul 15 03:09:57 2026 +0000
>
> mm/damon/tests/core-kunit: catch test failure in test_merge_regions_of()
>
> This commit fixes an issue where KUNIT_EXPECT_EQ() failures do not abort
> the test, leading to potential NULL pointer dereferences in subsequent
> code. It addresses this in damon_test_merge_regions_of() by explicitly
> checking the expectation and skipping the rest of the test if it fails.
>
> Link: https://lore.kernel.org/20260710144937.26981-1-sj@kernel.org
>
> > diff --git a/mm/damon/tests/core-kunit.h b/mm/damon/tests/core-kunit.h
> > index 485472ddebd19..eba643762132f 100644
> > --- a/mm/damon/tests/core-kunit.h
> > +++ b/mm/damon/tests/core-kunit.h
> > @@ -260,11 +260,14 @@ static void damon_test_merge_regions_of(struct kunit *test)
> > damon_merge_regions_of(t, 9, 9999, ctx, true);
> > /* 0-112, 114-130, 130-156, 156-170, 170-230, 230-10170 */
> > KUNIT_EXPECT_EQ(test, damon_nr_regions(t), 6u);
> > + if (damon_nr_regions(t) != 6)
> > + goto out;
> > for (i = 0; i < 6; i++) {
> > r = __nth_region_of(t, i);
> > KUNIT_EXPECT_EQ(test, r->ar.start, saddrs[i]);
> > KUNIT_EXPECT_EQ(test, r->ar.end, eaddrs[i]);
> > }
> > +out:
> > damon_free_target(t);
> > damon_destroy_ctx(ctx);
> > }
>
> [Severity: Medium]
> This is a pre-existing issue, but while you are fixing this anti-pattern
> here, the exact same missing abort condition exists in several other
> functions within the DAMON test suite.
>
> For example, in mm/damon/tests/core-kunit.h:damos_test_commit_dests_for():
>
> KUNIT_EXPECT_EQ(test, dst.nr_dests, src_nr_dests);
> for (i = 0; i < dst.nr_dests; i++) {
> KUNIT_EXPECT_EQ(test, dst.node_id_arr[i], src_node_id_arr[i]);
>
> If the expectation fails, could this loop read out-of-bounds on
> src_node_id_arr since it iterates based on dst.nr_dests?
>
> Similarly, in mm/damon/tests/core-kunit.h:damon_test_split_at():
>
> r_new = damon_next_region(r);
> KUNIT_EXPECT_EQ(test, r_new->ar.start, 25ul);
>
> Could damon_next_region() yield an invalid pointer if the split fails,
> causing a crash when r_new->ar.start is accessed unconditionally?
>
> The same unbounded array access or unsafe pointer dereference pattern
> appears to exist in:
> - mm/damon/tests/core-kunit.h:damos_test_commit_quota_goals_for()
> - mm/damon/tests/core-kunit.h:damon_test_commit_target_regions_for()
> - mm/damon/tests/core-kunit.h:damos_test_filter_out()
> - mm/damon/tests/vaddr-kunit.h:damon_do_test_apply_three_regions()
>
> Would it make sense to update these remaining occurrences in a follow-up or
> v2 of this patch to prevent slab corruption or NULL pointer dereferences
> during test failures?
I will fix those as a followup.
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260715031002.108504-1-sj@kernel.org?part=2
Thanks,
SJ
next prev parent reply other threads:[~2026-07-15 3:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-15 3:09 [PATCH v1.1 0/6] mm/damon: unurgent fixes for infinite loop, NULL de-ref and races SJ Park
2026-07-15 3:09 ` [PATCH v1.1 1/6] mm/damon/core: avoid infinite kdamond_merge_regions() internal loop SJ Park
2026-07-15 3:09 ` [PATCH v1.1 2/6] mm/damon/tests/core-kunit: catch test failure in test_merge_regions_of() SJ Park
2026-07-15 3:19 ` sashiko-bot
2026-07-15 3:31 ` SJ Park [this message]
2026-07-15 3:09 ` [PATCH v1.1 3/6] mm/damon/vaddr: drop last same folio access check optimization SJ Park
2026-07-15 3:09 ` [PATCH v1.1 4/6] mm/damon/paddr: drop last same folio access check reuse optimization SJ Park
2026-07-15 3:10 ` [PATCH v1.1 5/6] mm/damon/sysfs: read addr_unit only once in damon_sysfs_apply_inputs() SJ Park
2026-07-15 3:10 ` [PATCH v1.1 6/6] mm/damon/sysfs: read ops_id " SJ Park
2026-07-15 3:33 ` [PATCH v1.1 0/6] mm/damon: unurgent fixes for infinite loop, NULL de-ref and races SJ Park
2026-07-15 4:46 ` Andrew Morton
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=20260715033157.109327-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=damon@lists.linux.dev \
--cc=sashiko-bot@kernel.org \
/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.