Re: FAILED: patch "[PATCH] mm: prevent vm_area_struct::anon_name refcount saturation" failed to apply to 5.15-stable tree

[Sasha Levin <sashal@kernel.org>]

On Sun, Mar 06, 2022 at 10:37:21AM +0100, gregkh@linuxfoundation.org wrote:
>
>The patch below does not apply to the 5.15-stable tree.
>If someone wants it applied there, or to any other stable or longterm
>tree, then please email the backport, including the original git commit
>id to <stable@vger.kernel.org>.
>
>thanks,
>
>greg k-h
>
>------------------ original commit in Linus's tree ------------------
>
>From 96403e11283def1d1c465c8279514c9a504d8630 Mon Sep 17 00:00:00 2001
>From: Suren Baghdasaryan <surenb@google.com>
>Date: Fri, 4 Mar 2022 20:28:55 -0800
>Subject: [PATCH] mm: prevent vm_area_struct::anon_name refcount saturation
>
>A deep process chain with many vmas could grow really high.  With
>default sysctl_max_map_count (64k) and default pid_max (32k) the max
>number of vmas in the system is 2147450880 and the refcounter has
>headroom of 1073774592 before it reaches REFCOUNT_SATURATED
>(3221225472).
>
>Therefore it's unlikely that an anonymous name refcounter will overflow
>with these defaults.  Currently the max for pid_max is PID_MAX_LIMIT
>(4194304) and for sysctl_max_map_count it's INT_MAX (2147483647).  In
>this configuration anon_vma_name refcount overflow becomes theoretically
>possible (that still require heavy sharing of that anon_vma_name between
>processes).
>
>kref refcounting interface used in anon_vma_name structure will detect a
>counter overflow when it reaches REFCOUNT_SATURATED value but will only
>generate a warning and freeze the ref counter.  This would lead to the
>refcounted object never being freed.  A determined attacker could leak
>memory like that but it would be rather expensive and inefficient way to
>do so.
>
>To ensure anon_vma_name refcount does not overflow, stop anon_vma_name
>sharing when the refcount reaches REFCOUNT_MAX (2147483647), which still
>leaves INT_MAX/2 (1073741823) values before the counter reaches
>REFCOUNT_SATURATED.  This should provide enough headroom for raising the
>refcounts temporarily.

I think that this patch depends on 78db3412833d ("mm: add anonymous vma
name refcounting") which we don't have in any of the stable trees. (is
this why it wasn't tagged for stable?).

-- 
Thanks,
Sasha