linux-kernel - Re: [PATCH] maple_tree: Add dead node check in mas_dup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260103200633.246006-1-boudewijn@delta-utec.com>
Date: Sat,  3 Jan 2026 21:06:31 +0100
From: Boudewijn van der Heide <boudewijn@...ta-utec.com>
To: akpm@...ux-foundation.org
Cc: Liam.Howlett@...cle.com,
	aliceryhl@...gle.com,
	andrewjballance@...il.com,
	boudewijn@...ta-utec.com,
	linux-kernel@...r.kernel.org,
	linux-mm@...ck.org,
	maple-tree@...ts.infradead.org
Subject: Re: [PATCH] maple_tree: Add dead node check in mas_dup_alloc()

On Sat, 3 Jan 2026, Andrew Morton <akpm@...ux-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@...r.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@...r.kernel.org added.

Thanks,
Boudewijn