FAILED: patch "[PATCH] mm/damon/vaddr-kunit: check region count in three_regions" failed to apply to 5.15-stable tree
Subsystems (3)
[email protected]
maintainerThe patch below does not apply to the 5.15-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y
git checkout FETCH_HEAD
git cherry-pick -x 5fea07e460874c8c7cf00f728efbe22abc62c8d8
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<[email protected]>' --in-reply-to '2026090821-fancy-avoid-db90@gregkh' --subject-prefix 'PATCH 5.15.y' 'HEAD^..'
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 5fea07e460874c8c7cf00f728efbe22abc62c8d8 Mon Sep 17 00:00:00 2001
From: SJ Park <[email protected]>
Date: Fri, 17 Jul 2026 17:14:37 -0700
Subject: [PATCH] mm/damon/vaddr-kunit: check region count in three_regions
test
damon_do_test_apply_three_regions() iterates regions after damon_set_regions() call assuming the function would succeed at setting the number of regions the same to the expected one. It might have failed. In this case, __nth_region_of() in the iteration could return NULL and NULL dereference can happen in the test.
The consequent user impact (NULL dereference) is quite bad. The realistic user impact would be limited, though. It would affect only test run setups.
Fix it by testing if the number of regions was also changed as expected and exit early for the failure.
The issue was discovered [1] by Sashiko.
mm/damon/tests/vaddr-kunit.h +5 -0
@@ -158,12 +158,17 @@ static void damon_do_test_apply_three_regions(struct kunit *test,kunit_skip (test,"second damon_set_regions() fail" ); } +KUNIT_EXPECT_EQ (test,damon_nr_regions (t), nr_expected /2 ); +if (damon_nr_regions (t) != nr_expected /2 ) + goto out; +for (i =0 ; i < nr_expected /2 ; i++) { r =__nth_region_of (t, i);KUNIT_EXPECT_EQ (test, r->ar.start, expected[i *2 ]);KUNIT_EXPECT_EQ (test, r->ar.end, expected[i *2 +1 ]); } +out:damon_destroy_target (t,NULL ); }
SJ Park
maintainerPATCH 1/1 mm/damon/vaddr-kunit: check region count in three_regions test
damon_do_test_apply_three_regions() iterates regions after damon_set_regions() call assuming the function would succeed at setting the number of regions the same to the expected one. It might have failed. In this case, __nth_region_of() in the iteration could return NULL and NULL dereference can happen in the test.
The consequent user impact (NULL dereference) is quite bad. The realistic user impact would be limited, though. It would affect only test run setups.
Fix it by testing if the number of regions was also changed as expected and exit early for the failure.
The issue was discovered [1] by Sashiko.
--- mm/damon/vaddr-test.h | 5 +++++ 1 file changed, 5 insertions(+)
mm/damon/vaddr-test.h +5 -0
@@ -155,12 +155,17 @@ static void damon_do_test_apply_three_regions(struct kunit *test,damon_va_apply_three_regions (t, three_regions); +KUNIT_EXPECT_EQ (test,damon_nr_regions (t), nr_expected /2 ); +if (damon_nr_regions (t) != nr_expected /2 ) + goto out; +for (i =0 ; i < nr_expected /2 ; i++) { r =__nth_region_of (t, i);KUNIT_EXPECT_EQ (test, r->ar.start, expected[i *2 ]);KUNIT_EXPECT_EQ (test, r->ar.end, expected[i *2 +1 ]); } +out:damon_destroy_ctx (ctx); }
Signature · 1 line
2.47.3
[email protected]
AI reviewRe: [PATCH 5.15.y] mm/damon/vaddr-kunit: check region count in three_regions test
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Missing checks for expected region counts in DAMON kunit tests cause NULL pointer dereferences and out-of-bounds accesses.
- [High] Missing NULL checks for damon_new_ctx() allocations in KUnit tests lead to kernel oopses.
--
commit 18eda53adc9f6ea23835c180d70b57969be3e82f
Author: SJ Park <[email protected]>
mm/damon/vaddr-kunit: check region count in three_regions test
damon_do_test_apply_three_regions() iterates regions after a setup call assuming it would succeed at setting the number of regions to the expected one. Fix it by testing if the number of regions was changed as expected and exit early for the failure to prevent a NULL dereference.
mm/damon/vaddr-test.h static void damon_do_test_apply_three_regions(struct kunit *test, · line 161
Quoted 12 lines
mm/damon/vaddr-test.h +4
-0@@ -155,12 +155,17 @@ static void damon_do_test_apply_three_regions(struct kunit *test,damon_va_apply_three_regions (t, three_regions); +KUNIT_EXPECT_EQ (test,damon_nr_regions (t), nr_expected /2 ); +if (damon_nr_regions (t) != nr_expected /2 ) + goto out; +
[Severity: High]
This isn't a bug introduced by this patch, but I noticed a missing NULL check for the damon_new_ctx() allocation earlier in this same function:
mm/damon/vaddr-test.h:damon_do_test_apply_three_regions() {
struct damon_ctx *ctx = damon_new_ctx();
...
damon_add_target(ctx, t);
}If damon_new_ctx() fails under memory pressure, does this cause a NULL pointer dereference in damon_add_target()?
Similarly, does damon_test_split_evenly() miss a NULL check for damon_new_ctx()?
mm/damon/vaddr-test.h:damon_test_split_evenly() {
struct damon_ctx *c = damon_new_ctx();
...
damon_destroy_ctx(c);
}Will damon_destroy_ctx() unconditionally dereference it if c is NULL?
[Severity: High]
This is a pre-existing issue, but it appears there are identical missing region count checks in other test functions that can lead to NULL pointer dereferences or out-of-bounds accesses.
For instance, in mm/damon/core-test.h:damon_test_merge_regions_of():
KUNIT_EXPECT_EQ(test, damon_nr_regions(t), 5u);
for (i = 0; i < 5; 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]);
}If the regions are fewer than expected, will __nth_region_of() return NULL and be unconditionally dereferenced?
Similarly, in mm/damon/core-test.h:damon_test_split_at():
damon_split_region_at(c, t, r, 25); ... r = damon_next_region(r); KUNIT_EXPECT_EQ(test, r->ar.start, 25ul);
If damon_split_region_at() fails, r remains the only element, so does damon_next_region(r) resolve to the list head offset, leading to an out-of-bounds read on r->ar.start?
And in mm/damon/vaddr-test.h:damon_test_split_evenly_succ():
damon_for_each_region(r, t) {
if (i == nr_pieces - 1)
break;
KUNIT_EXPECT_EQ(test,
r->ar.start, start + i++ * expected_width);
KUNIT_EXPECT_EQ(test, r->ar.end, start + i * expected_width);
}
KUNIT_EXPECT_EQ(test, r->ar.start, start + i * expected_width);If damon_va_evenly_split_region() fails, does the loop terminate normally without hitting the break condition, causing an out-of-bounds read when accessing r->ar.start after the loop?
Quoted 9 lines
mm/damon/vaddr-test.h +1
-0for (i =0 ; i < nr_expected /2 ; i++) { r =__nth_region_of (t, i);KUNIT_EXPECT_EQ (test, r->ar.start, expected[i *2 ]);KUNIT_EXPECT_EQ (test, r->ar.end, expected[i *2 +1 ]); } +out:damon_destroy_ctx (ctx); }
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
Re: [PATCH 5.15.y] mm/damon/vaddr-kunit: check region count in three_regions test
In reply to SJ ParkQuoted 3 lines
damon_do_test_apply_three_regions()iterates regions afterdamon_set_regions()call assuming the function would succeed at setting the number of regions the same to the expected one. It might have failed.
Queued for 5.15, thanks.
Signature · 2 lines
Thanks, Sasha