Re: [PATCH 2/7] mm/damon/core-kunit: check region count before testing in split_at()

[SJ Park <sj@kernel.org>]

On Sat, 18 Jul 2026 00:30:26 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> 
> Pre-existing issues:
> - [High] Silent allocation failure inside `damon_split_region_at()` causes an improper pointer traversal into the list head in `damon_apply_min_nr_regions()`, resulting in a potential infinite loop and out-of-bounds memory corruption.
> - [Medium] The patch fixes an invalid pointer dereference upon split allocation failure in `damon_test_split_at()`, but misses an identical vulnerability in `damos_test_filter_out()`.
> --
> 
> --- Patch [2]: [PATCH 2/7] mm/damon/core-kunit: check region count before testing in split_at() ---
> commit 97ba538eacadf2d58d517d9d0f86ecaac4b3851f
> Author: SJ Park <sj@kernel.org>
> Subject: mm/damon/core-kunit: check region count before testing in split_at()
> 
> This commit fixes an issue in the KUnit tests where damon_test_split_at()
> could dereference invalid pointers if a region split fails to allocate
> memory. The fix tests if the number of regions was changed as expected
> and exits early upon failure.
> 
> Link: https://lore.kernel.org/20260714142352.100478-1-sj@kernel.org
> 
> > diff --git a/mm/damon/tests/core-kunit.h b/mm/damon/tests/core-kunit.h
> > index eba643762132f..322a295ac2cec 100644
> > --- a/mm/damon/tests/core-kunit.h
> > +++ b/mm/damon/tests/core-kunit.h
> > @@ -155,6 +155,10 @@ static void damon_test_split_at(struct kunit *test)
> >  	r->age = 10;
> >  	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;
> > +
> >  	KUNIT_EXPECT_EQ(test, r->ar.start, 0ul);
> >  	KUNIT_EXPECT_EQ(test, r->ar.end, 25ul);
> 
> [Severity: Medium]
> This isn't a bug introduced by this patch, but this exact same vulnerability
> seems to exist later in this file in damos_test_filter_out().
> 
> If damos_filter_match() internally fails to allocate memory during a region
> split, the test continues and damon_next_region(r) returns the list head.
> 
> mm/damon/tests/core-kunit.h:damos_test_filter_out() {
> ...
> 	/* region started before the range */
> 	r->ar.start = 1;
> 	r->ar.end = 4;
> 	KUNIT_EXPECT_FALSE(test, damos_filter_match(NULL, t, r, f, 1));
> 	/* filter should have split the region */
> 	KUNIT_EXPECT_EQ(test, r->ar.start, 1);
> 	KUNIT_EXPECT_EQ(test, r->ar.end, 2);
> 	KUNIT_EXPECT_EQ(test, damon_nr_regions(t), 2);
> 	r2 = damon_next_region(r);
> 	KUNIT_EXPECT_EQ(test, r2->ar.start, 2);
> 	KUNIT_EXPECT_EQ(test, r2->ar.end, 4);
> 	damon_destroy_region(r2, t);
> ...
> }
> 
> Should the test also be checking the region count and returning early here,
> before we pass an invalid pointer to damon_destroy_region() and corrupt the
> slab?

This is fixed by a later patch of this series.

> 
> [Severity: High]
> This is a pre-existing issue, but I'm also concerned about silent allocation
> failures from damon_split_region_at() in core kernel paths.
> 
> Looking at damon_apply_min_nr_regions():
> 
> mm/damon/core.c:damon_apply_min_nr_regions() {
> ...
> 	damon_for_each_target(t, ctx) {
> 		damon_for_each_region_safe(r, next, t) {
> 			while (damon_sz_region(r) > max_region_sz) {
> 				damon_split_region_at(t, r, max_region_sz);
> 				r = damon_next_region(r);
> 			}
> 		}
> 	}
> ...
> }
> 
> If damon_split_region_at() silently fails to allocate memory, it returns
> without splitting the region. The while loop then incorrectly advances r
> to the next region.
> 
> If this allocation failure occurs on the last region in the list,
> damon_next_region(r) will return the list head.
> 
> The loop condition damon_sz_region(r) > max_region_sz will evaluate memory
> located before the damon_target struct.
> 
> If those garbage values evaluate to true, could this result in an out-of-bounds
> access loop or corrupt memory? Should damon_split_region_at() return an
> error code that callers can check?

I'm separately working [1] on it.

[1] https://lore.kernel.org/20260718004301.88883-1-sj@kernel.org

> 
> [ ... ]
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260718001442.87129-1-sj@kernel.org?part=2


Thanks,
SJ