From: Boudewijn van der Heide <boudewijn@delta-utec.com>
To: akpm@linux-foundation.org
Cc: Liam.Howlett@oracle.com, aliceryhl@google.com,
andrewjballance@gmail.com, boudewijn@delta-utec.com,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
maple-tree@lists.infradead.org
Subject: Re: [PATCH] maple_tree: Add dead node check in mas_dup_alloc()
Date: Sat, 3 Jan 2026 21:06:31 +0100 [thread overview]
Message-ID: <20260103200633.246006-1-boudewijn@delta-utec.com> (raw)
In-Reply-To: <20260103103247.9140cb2556280927b09f59d3@linux-foundation.org>
On Sat, 3 Jan 2026, Andrew Morton <akpm@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@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@vger.kernel.org added.
Thanks,
Boudewijn
next prev parent reply other threads:[~2026-01-03 20:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-03 16:57 Boudewijn van der Heide
2026-01-03 18:32 ` Andrew Morton
2026-01-03 20:06 ` Boudewijn van der Heide [this message]
2026-01-06 1:33 ` Andrew Morton
2026-01-06 2:49 ` Matthew Wilcox
2026-01-06 3:40 ` Andrew Morton
2026-01-06 13:24 ` Boudewijn van der Heide
2026-01-06 16:01 ` Liam R. Howlett
2026-01-06 16:48 ` Boudewijn van der Heide
2026-01-06 18:29 ` Matthew Wilcox
2026-01-06 20:07 ` Liam R. Howlett
2026-01-06 21:07 ` [PATCH v2] maple_tree: Add lockdep assertion " Boudewijn van der Heide
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=20260103200633.246006-1-boudewijn@delta-utec.com \
--to=boudewijn@delta-utec.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=aliceryhl@google.com \
--cc=andrewjballance@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=maple-tree@lists.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