[PATCH] maple_tree: Add dead node check in mas_dup_alloc()
Boudewijn van der Heide
boudewijn at delta-utec.com
Sat Jan 3 12:06:31 PST 2026
On Sat, 3 Jan 2026, Andrew Morton <akpm at linux-foundation.org> wrote:
> What are the worst-case userspace-visible runtime effects when this
> happens?
Worst case: if __mt_dup() is invoked without the required external
locking and the source tree is concurrently modified, a node can
transition to the “dead” RCU layout while mas_dup_alloc() is still
traversing it. In that case the code may interpret the rcu_head contents
as slot pointers.
Practically, this could lead to invalid pointer dereferences (kernel
oops) or corruption of the duplicated tree. Depending on how that
duplicated tree is later used (e.g. in mm/VMA paths), the effects could
be userspace-visible, such as fork() failures, process crashes, or
broader system instability.
My understanding is that current in-tree users hold the appropriate
locks and should not hit this, as triggering it requires violating the
__mt_dup() synchronization contract. The risk primarily comes from the
fact that __mt_dup() is exported (EXPORT_SYMBOL), making it reachable by
out-of-tree modules or future callers which may not follow the locking
rules.
> If they're bad then presumably we'll want to backport this fix into
> earlier kernels with a Cc: <stable at vger.kernel.org> and, very
> preferably a Fixes: line.
The function was introduced without the check here:
Fixes: fd32e4e9b764 ("maple_tree: introduce interfaces __mt_dup() and mtree_dup()")
If you think this warrants stable backporting as a safety fix,
I’m happy to send a v2 with the Fixes: tag and Cc: stable at vger.kernel.org added.
Thanks,
Boudewijn
More information about the maple-tree
mailing list