[PATCH mm] kasan: reset page tags properly with sampling

0 views
Skip to first unread message

andrey.k...@linux.dev

unread,
Jan 24, 2023, 3:35:32 PM1/24/23
to Andrew Morton, Andrey Konovalov, Marco Elver, Alexander Potapenko, Dmitry Vyukov, Andrey Ryabinin, kasa...@googlegroups.com, linu...@kvack.org, linux-...@vger.kernel.org, Andrey Konovalov, Peter Collingbourne
From: Andrey Konovalov <andre...@google.com>

The implementation of page_alloc poisoning sampling assumed that
tag_clear_highpage resets page tags for __GFP_ZEROTAGS allocations.
However, this is no longer the case since commit 70c248aca9e7
("mm: kasan: Skip unpoisoning of user pages").

This leads to kernel crashes when MTE-enabled userspace mappings are
used with Hardware Tag-Based KASAN enabled.

Reset page tags for __GFP_ZEROTAGS allocations in post_alloc_hook().

Also clarify and fix related comments.

Reported-by: Peter Collingbourne <p...@google.com>
Tested-by: Peter Collingbourne <p...@google.com>
Signed-off-by: Andrey Konovalov <andre...@google.com>
---
mm/page_alloc.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 5514d84cc712..370d4f2c0276 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2471,7 +2471,7 @@ inline void post_alloc_hook(struct page *page, unsigned int order,
bool init = !want_init_on_free() && want_init_on_alloc(gfp_flags) &&
!should_skip_init(gfp_flags);
bool zero_tags = init && (gfp_flags & __GFP_ZEROTAGS);
- bool reset_tags = !zero_tags;
+ bool reset_tags = true;
int i;

set_page_private(page, 0);
@@ -2498,7 +2498,7 @@ inline void post_alloc_hook(struct page *page, unsigned int order,
* (which happens only when memory should be initialized as well).
*/
if (zero_tags) {
- /* Initialize both memory and tags. */
+ /* Initialize both memory and memory tags. */
for (i = 0; i != 1 << order; ++i)
tag_clear_highpage(page + i);

@@ -2516,14 +2516,14 @@ inline void post_alloc_hook(struct page *page, unsigned int order,
} else {
/*
* KASAN decided to exclude this allocation from being
- * poisoned due to sampling. Skip poisoning as well.
+ * unpoisoned due to sampling. Skip poisoning as well.
*/
SetPageSkipKASanPoison(page);
}
}
/*
- * If memory tags have not been set, reset the page tags to ensure
- * page_address() dereferencing does not fault.
+ * If memory tags have not been set by KASAN, reset the page tags to
+ * ensure page_address() dereferencing does not fault.
*/
if (reset_tags) {
for (i = 0; i != 1 << order; ++i)
--
2.25.1

andrey.k...@linux.dev

unread,
Jan 24, 2023, 3:40:13 PM1/24/23
to Andrew Morton, Andrey Konovalov, Marco Elver, Alexander Potapenko, Dmitry Vyukov, Andrey Ryabinin, kasa...@googlegroups.com, linu...@kvack.org, linux-...@vger.kernel.org, Andrey Konovalov, Peter Collingbourne
From: Andrey Konovalov <andre...@google.com>

The implementation of page_alloc poisoning sampling assumed that
tag_clear_highpage resets page tags for __GFP_ZEROTAGS allocations.
However, this is no longer the case since commit 70c248aca9e7
("mm: kasan: Skip unpoisoning of user pages").

This leads to kernel crashes when MTE-enabled userspace mappings are
used with Hardware Tag-Based KASAN enabled.

Reset page tags for __GFP_ZEROTAGS allocations in post_alloc_hook().

Also clarify and fix related comments.

Reported-by: Peter Collingbourne <p...@google.com>
Tested-by: Peter Collingbourne <p...@google.com>
Signed-off-by: Andrey Konovalov <andre...@google.com>
---
mm/page_alloc.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 5514d84cc712..b917aebfd3d0 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2471,7 +2471,7 @@ inline void post_alloc_hook(struct page *page, unsigned int order,
bool init = !want_init_on_free() && want_init_on_alloc(gfp_flags) &&
!should_skip_init(gfp_flags);
bool zero_tags = init && (gfp_flags & __GFP_ZEROTAGS);
- bool reset_tags = !zero_tags;
+ bool reset_tags = true;
int i;

set_page_private(page, 0);
@@ -2498,7 +2498,7 @@ inline void post_alloc_hook(struct page *page, unsigned int order,
* (which happens only when memory should be initialized as well).
*/
if (zero_tags) {
- /* Initialize both memory and tags. */
+ /* Initialize both memory and memory tags. */
for (i = 0; i != 1 << order; ++i)
tag_clear_highpage(page + i);

@@ -2516,14 +2516,15 @@ inline void post_alloc_hook(struct page *page, unsigned int order,
} else {
/*
* KASAN decided to exclude this allocation from being
- * poisoned due to sampling. Skip poisoning as well.
+ * (un)poisoned due to sampling. Make KASAN skip
+ * poisoning when the allocation is freed.

Andrew Morton

unread,
Jan 24, 2023, 3:45:08 PM1/24/23
to andrey.k...@linux.dev, Andrey Konovalov, Marco Elver, Alexander Potapenko, Dmitry Vyukov, Andrey Ryabinin, kasa...@googlegroups.com, linu...@kvack.org, linux-...@vger.kernel.org, Andrey Konovalov, Peter Collingbourne
On Tue, 24 Jan 2023 21:35:26 +0100 andrey.k...@linux.dev wrote:

> The implementation of page_alloc poisoning sampling assumed that
> tag_clear_highpage resets page tags for __GFP_ZEROTAGS allocations.
> However, this is no longer the case since commit 70c248aca9e7
> ("mm: kasan: Skip unpoisoning of user pages").
>
> This leads to kernel crashes when MTE-enabled userspace mappings are
> used with Hardware Tag-Based KASAN enabled.
>
> Reset page tags for __GFP_ZEROTAGS allocations in post_alloc_hook().
>
> Also clarify and fix related comments.

I assume this is a fix against 44383cef54c0 ("kasan: allow sampling
page_alloc allocations for HW_TAGS") which is presently in mm-stable,
yes?


Andrey Konovalov

unread,
Jan 24, 2023, 3:47:03 PM1/24/23
to Andrew Morton, andrey.k...@linux.dev, Marco Elver, Alexander Potapenko, Dmitry Vyukov, Andrey Ryabinin, kasa...@googlegroups.com, linu...@kvack.org, linux-...@vger.kernel.org, Andrey Konovalov, Peter Collingbourne
Correct. I assumed I shouldn't include a Fixes tag, as the patch is
not in the mainline.

Andrew Morton

unread,
Jan 24, 2023, 4:11:26 PM1/24/23
to Andrey Konovalov, andrey.k...@linux.dev, Marco Elver, Alexander Potapenko, Dmitry Vyukov, Andrey Ryabinin, kasa...@googlegroups.com, linu...@kvack.org, linux-...@vger.kernel.org, Andrey Konovalov, Peter Collingbourne
I think it's best to add the Fixes: if it's known. If the patch was in
mm-unstable then I'd just fold the fix into the base patch, but a
Fixes: is still helpful because it tells people (especially me) which
patch needs the fix.

If the patch is in mm-stable then the SHA is stable and the Fixes: is
desirable for people who are backporting the base patch into earlier
kernels - hopefully when doing this they know to search the tree for
other patches which fix the patch which they are backporting.
Reply all
Reply to author
Forward
0 new messages