On Sun, Mar 06, 2022 at 04:50:42PM -0500, Sasha Levin wrote:
> On Sun, Mar 06, 2022 at 10:37:21AM +0100, gregkh@xxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxx>.
> >
> > thanks,
> >
> > greg k-h
> >
> > ------------------ original commit in Linus's tree ------------------
> >
> > > From 96403e11283def1d1c465c8279514c9a504d8630 Mon Sep 17 00:00:00 2001
> > From: Suren Baghdasaryan <surenb@xxxxxxxxxx>
> > 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 :)
thanks,
greg k-h
