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

From: Suren Baghdasaryan <surenb@google.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Sasha Levin <sashal@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christian Brauner <brauner@kernel.org>,
	caoxiaofeng@yulong.com, Colin Cross <ccross@google.com>,
	Chris Hyser <chris.hyser@oracle.com>,
	Dave Hansen <dave.hansen@intel.com>,
	Davidlohr Bueso <dave@stgolabs.net>,
	David Hildenbrand <david@redhat.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Cyrill Gorcunov <gorcunov@gmail.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Kees Cook <keescook@chromium.org>,
	"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
	legion@kernel.org, Michal Hocko <mhocko@suse.com>,
	Peter Collingbourne <pcc@google.com>,
	Sumit Semwal <sumit.semwal@linaro.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	Matthew Wilcox <willy@infradead.org>,
	stable <stable@vger.kernel.org>
Subject: Re: FAILED: patch "[PATCH] mm: prevent vm_area_struct::anon_name refcount saturation" failed to apply to 5.15-stable tree
Date: Sun, 6 Mar 2022 14:53:10 -0800	[thread overview]
Message-ID: <CAJuCfpH+bSx7jtqfSwrZkKxFrp+b8sc5zRixrEFCKh_-xSnQkA@mail.gmail.com> (raw)
In-Reply-To: <YiUuo8o9+OKkNs1u@kroah.com>

On Sun, Mar 6, 2022 at 1:59 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Sun, Mar 06, 2022 at 04:50:42PM -0500, Sasha Levin wrote:
> > 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?).
>
> Suren said he would provide a backport on Monday, so let's see what he
> comes up with :)

Ah, right. We don't have anonymous vma name support in 5.16 or earlier
kernels, so this patch is indeed not needed there.

>
> thanks,
>
> greg k-h