From: Florian Schmaus <florian.schmaus@codasip.com>
To: Andrew Morton <akpm@linux-foundation.org>,
"Liam R. Howlett" <liam@infradead.org>,
Alice Ryhl <aliceryhl@google.com>,
Andrew Ballance <andrewjballance@gmail.com>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
Suren Baghdasaryan <surenb@google.com>
Cc: linux-kernel@vger.kernel.org, maple-tree@lists.infradead.org,
linux-mm@kvack.org,
Florian Schmaus <florian.schmaus@codasip.com>,
"Liam R. Howlett" <liam@infradead.org>
Subject: [PATCH 2/3] maple_tree: do not clear the metadata of a full dead node
Date: Thu, 15 Oct 2026 17:11:16 +0200 [thread overview]
Message-ID: <20261015-maple-tree-fix-slab-corruption-v1-2-160d97f7304c@codasip.com> (raw)
In-Reply-To: <20261015-maple-tree-fix-slab-corruption-v1-0-160d97f7304c@codasip.com>
When an RCU-mode tree that is not an allocation tree is destroyed, or a
subtree of such a tree is replaced by a spanning store, mt_destroy_walk()
runs with free == false and the nodes are freed later by mt_free_walk().
mte_dead_leaves() replaces the slots of each dead node with plain node
pointers, which lack the type bits of an encoded node. Afterwards,
mt_clear_meta() clears the metadata of the start node.
A maple_range_64 node keeps its metadata in the last slot, unless that
slot holds a child. mt_clear_meta() recognizes a child only by its type
bits. For a full node (16 children), it therefore takes the last child
for metadata and zeroes two bytes of the pointer (the low bytes on
little-endian). mt_free_walk() then frees the resulting address, which
usually points into another node, live or already freed, and corrupts
the slab.
Storing 120 disjoint ranges into an MT_FLAGS_USE_RCU tree (a full root
of height 2) and then calling mtree_destroy() and rcu_barrier() in the
userspace test harness under ASan gives:
ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7c64552f0000
WRITE of size 256 at 0x7c64552f0000 thread T1
#3 kmem_cache_free_bulk ../shared/linux.c:149
#4 mt_free_bulk ../shared/../../../lib/maple_tree.c:144
#5 mt_free_walk ../shared/../../../lib/maple_tree.c:4784
A full maple_range_64 node has no metadata, so do not clear it.
Allocation trees, such as mm_mt, are not affected because their
maple_arange_64 nodes keep the metadata in a separate field.
Fixes: 2e5b4921f8ef ("maple_tree: fix freeing of nodes in rcu mode")
Signed-off-by: Florian Schmaus <florian.schmaus@codasip.com>
---
lib/maple_tree.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/lib/maple_tree.c b/lib/maple_tree.c
index e5c0eeda0bd7..05546aa53871 100644
--- a/lib/maple_tree.c
+++ b/lib/maple_tree.c
@@ -4886,9 +4886,17 @@ static void mt_destroy_walk(struct maple_enode *enode, struct maple_tree *mt,
mt_free_bulk(node->slot_len, slots);
free_leaf:
+ /*
+ * A full maple_range_64 node has no metadata: its last slot holds a
+ * child. mt_clear_meta() cannot tell, because mte_dead_leaves() has
+ * stripped the type bits from the child pointers, and would zero part
+ * of that child pointer. slot_len, the child count returned by
+ * mte_dead_leaves(), says whether the node is full.
+ */
if (free)
kfree(node);
- else
+ else if (node->type != maple_range_64 ||
+ node->slot_len < MAPLE_RANGE64_SLOTS)
mt_clear_meta(mt, node, node->type);
}
--
2.55.0
next prev parent reply other threads:[~2026-10-15 15:11 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-15 15:11 [PATCH 0/3] maple_tree: fix two bugs when freeing RCU-mode trees Florian Schmaus
2026-10-15 15:11 ` [PATCH 1/3] maple_tree: do not descend into metadata in mt_free_walk() Florian Schmaus
2026-10-15 15:11 ` Florian Schmaus [this message]
2026-10-15 15:11 ` [PATCH 3/3] maple_tree: add a test for destroying RCU-mode trees Florian Schmaus
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=20261015-maple-tree-fix-slab-corruption-v1-2-160d97f7304c@codasip.com \
--to=florian.schmaus@codasip.com \
--cc=akpm@linux-foundation.org \
--cc=aliceryhl@google.com \
--cc=andrewjballance@gmail.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=maple-tree@lists.infradead.org \
--cc=surenb@google.com \
--cc=willy@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®