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

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 <[email protected]>
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/[email protected]

> 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?

[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?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2