All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "SJ Park" <sj@kernel.org>
Cc: damon@lists.linux.dev
Subject: Re: [PATCH 6.6.y] mm/damon/core-kunit: check region count before testing in split_at()
Date: Wed, 09 Sep 2026 04:13:26 +0000	[thread overview]
Message-ID: <20260909041327.4EB821F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260909040016.165245-1-sj@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Medium] The patch addresses an invalid pointer dereference in `damon_test_split_at()` by checking `damon_nr_regions(t) != 2` after a split failure, but misses the exact same vulnerability in `damos_test_filter_out()`, which will cause a kernel panic if a split fails.
--

commit eea94ba78cece48ae60d9049e4528675f25050ea
Author: SJ Park <sj@kernel.org>

mm/damon/core-kunit: check region count before testing in split_at()

The commit addresses an issue in damon_test_split_at() where a failure
during region splitting would cause the subsequent code to dereference an
invalid pointer. By checking if the region count is 2 after the split,
the test now correctly exits early on failure. This fixes a potential
memory corruption issue during test execution.

Link: https://lore.kernel.org/20260718001442.87129-3-sj@kernel.org
Link: https://lore.kernel.org/20260714142352.100478-1-sj@kernel.org [1]

> diff --git a/mm/damon/core-test.h b/mm/damon/core-test.h
> index a2aa410d6d0d0..f2f0978495086 100644
> --- a/mm/damon/core-test.h
> +++ b/mm/damon/core-test.h
> @@ -162,6 +162,10 @@ static void damon_test_split_at(struct kunit *test)
>  	}
>  	damon_add_region(r, t);
>  	damon_split_region_at(t, r, 25);
> +	KUNIT_EXPECT_EQ(test, damon_nr_regions(t), 2);
> +	if (damon_nr_regions(t) != 2)
> +		goto out;
> +

[Severity: Medium]
This is a pre-existing issue, but does damos_test_filter_out() in the same
file suffer from the exact same missing failure check?

If memory allocation fails during region splitting in __damos_filter_out(),
damon_nr_regions(t) remains 1. The test code expects 2, but KUNIT_EXPECT_EQ()
does not abort execution:

	/* filter should have split the region */
	KUNIT_EXPECT_EQ(test, r->ar.start, DAMON_MIN_REGION * 1);
	KUNIT_EXPECT_EQ(test, r->ar.end, DAMON_MIN_REGION * 2);
	KUNIT_EXPECT_EQ(test, damon_nr_regions(t), 2);
	r2 = damon_next_region(r);
	KUNIT_EXPECT_EQ(test, r2->ar.start, DAMON_MIN_REGION * 2);
	KUNIT_EXPECT_EQ(test, r2->ar.end, DAMON_MIN_REGION * 4);
	damon_destroy_region(r2, t);

Could passing the invalid pointer returned by damon_next_region() to
damon_destroy_region() lead to a crash when it executes list_del() and
kmem_cache_free() on the corrupted pointer?

A similar pattern also occurs slightly later in the same function:

	/* filter should have split the region */
	KUNIT_EXPECT_EQ(test, r->ar.start, DAMON_MIN_REGION * 2);
	KUNIT_EXPECT_EQ(test, r->ar.end, DAMON_MIN_REGION * 6);
	KUNIT_EXPECT_EQ(test, damon_nr_regions(t), 2);
	r2 = damon_next_region(r);
	KUNIT_EXPECT_EQ(test, r2->ar.start, DAMON_MIN_REGION * 6);
	KUNIT_EXPECT_EQ(test, r2->ar.end, DAMON_MIN_REGION * 8);
	damon_destroy_region(r2, t);

Should similar early exits be added in damos_test_filter_out() to prevent
this?

>  	KUNIT_EXPECT_EQ(test, r->ar.start, 0ul);
>  	KUNIT_EXPECT_EQ(test, r->ar.end, 25ul);
>  
> @@ -169,6 +173,7 @@ static void damon_test_split_at(struct kunit *test)
>  	KUNIT_EXPECT_EQ(test, r->ar.start, 25ul);
>  	KUNIT_EXPECT_EQ(test, r->ar.end, 100ul);
>  
> +out:
>  	damon_free_target(t);
>  	damon_destroy_ctx(c);
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260909040016.165245-1-sj@kernel.org?part=1

  reply	other threads:[~2026-09-09  4:13 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <2026090820-attest-sheep-bc32@gregkh>
2026-09-09  4:00 ` [PATCH 6.6.y] mm/damon/core-kunit: check region count before testing in split_at() SJ Park
2026-09-09  4:13   ` sashiko-bot [this message]
2026-09-09 20:26   ` Sasha Levin

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=20260909041327.4EB821F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=damon@lists.linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=sj@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.