[PATCH] maple_tree: Add dead node check in mas_dup_alloc()

Andrew Morton akpm at linux-foundation.org
Mon Jan 5 17:33:50 PST 2026


On Sat,  3 Jan 2026 21:06:31 +0100 Boudewijn van der Heide <boudewijn at delta-utec.com> wrote:

> 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()")
> 

Great, thanks, I added all that to the changelog and queued this in
mm.git as a hotfix, for runtime testing and pending reviewer input.



More information about the maple-tree mailing list