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: <20260105173350.d8ad7d630be1f0a581dfd565@linux-foundation.org>
Date: Mon, 5 Jan 2026 17:33:50 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Boudewijn van der Heide <boudewijn@...ta-utec.com>
Cc: Liam.Howlett@...cle.com, aliceryhl@...gle.com,
 andrewjballance@...il.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 21:06:31 +0100 Boudewijn van der Heide <boudewijn@...ta-utec.com> wrote:

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

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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ