From: Suren Baghdasaryan <surenb@google.com>
To: Michal Hocko <mhocko@suse.com>
Cc: akpm@linux-foundation.org, ccross@google.com,
sumit.semwal@linaro.org, dave.hansen@intel.com,
keescook@chromium.org, willy@infradead.org,
kirill.shutemov@linux.intel.com, vbabka@suse.cz,
hannes@cmpxchg.org, ebiederm@xmission.com, brauner@kernel.org,
legion@kernel.org, ran.xiaokai@zte.com.cn, sashal@kernel.org,
chris.hyser@oracle.com, dave@stgolabs.net, pcc@google.com,
caoxiaofeng@yulong.com, david@redhat.com, gorcunov@gmail.com,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
kernel-team@android.com
Subject: Re: [PATCH 2/3] mm: prevent vm_area_struct::anon_name refcount saturation
Date: Tue, 22 Feb 2022 19:02:08 -0800 [thread overview]
Message-ID: <CAJuCfpFkwZAw-qcD6E5SchHNXf8MmzyWtuWaHOpFhid3m5bg8A@mail.gmail.com> (raw)
In-Reply-To: <CAJuCfpHr78By6p5sMhJZ3UohKXXSeA7Dxm_q-OA4y6KYL0L_pQ@mail.gmail.com>
On Tue, Feb 22, 2022 at 7:56 AM Suren Baghdasaryan <surenb@google.com> wrote:
>
> On Tue, Feb 22, 2022 at 1:17 AM Michal Hocko <mhocko@suse.com> wrote:
> >
> > On Mon 21-02-22 21:40:24, Suren Baghdasaryan wrote:
> > > A deep process chain with many vmas could grow really high.
> >
> > This would really benefit from some numbers. With default
> > sysctl_max_map_count (64k) and default pid_max (32k) the INT_MAX could
> > be theoretically reached but I find it impractical because not all vmas
> > can be anonymous same as all available pids can be consumed for a
> > theoretical attack (if my counting is proper).
> > On the other hand any non-default configuration with any of the values
> > increased could hit this theoretically.
>
> re: This would really benefit from some numbers
> Should I just add the details you provided above into the description?
> Would that suffice?
Hmm. According to the defaults you posted, with max number of
processes being 32k and max number of vmas per process 64k, the max
number of vmas in the system is 2147450880. That's 32767 less than
REFCOUNT_MAX=INT_MAX (2147483647) and 1073774592 less than
REFCOUNT_SATURATED (3221225472). So with those defaults we should
never hit these limits. Are we adding this protection for systems that
set non-default higher limits or am I miscalculating something?
>
> >
> > > 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 about broken refcounting.
> > > To ensure anon_vma_name refcount does not overflow, stop anon_vma_name
> > > sharing when the refcount reaches INT_MAX, which still leaves INT_MAX/2
> > > values before the counter reaches REFCOUNT_SATURATED. This should provide
> > > enough headroom for raising the refcounts temporarily.
> > >
> > > Suggested-by: Michal Hocko <mhocko@suse.com>
> > > Signed-off-by: Suren Baghdasaryan <surenb@google.com>
> > > ---
> > > include/linux/mm_inline.h | 18 ++++++++++++++----
> > > mm/madvise.c | 3 +--
> > > 2 files changed, 15 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/include/linux/mm_inline.h b/include/linux/mm_inline.h
> > > index 70b619442d56..b189e2638843 100644
> > > --- a/include/linux/mm_inline.h
> > > +++ b/include/linux/mm_inline.h
> > > @@ -156,15 +156,25 @@ static inline void anon_vma_name_get(struct anon_vma_name *anon_name)
> > >
> > > extern void anon_vma_name_put(struct anon_vma_name *anon_name);
> > >
> > > +static inline
> > > +struct anon_vma_name *anon_vma_name_reuse(struct anon_vma_name *anon_name)
> > > +{
> > > + /* Prevent anon_name refcount saturation early on */
> > > + if (kref_read(&anon_name->kref) < INT_MAX) {
> >
> > REFCOUNT_MAX seems to be defined by the kref framework.
>
> Ah, indeed. I missed that. Will change to use it.
>
> >
> > Other than that looks good to me.
>
> Thanks for the review!
>
> >
> > > + anon_vma_name_get(anon_name);
> > > + return anon_name;
> > > +
> > > + }
> > > + return anon_vma_name_alloc(anon_name->name);
> > > +}
> > > +
> > > static inline void dup_vma_anon_name(struct vm_area_struct *orig_vma,
> > > struct vm_area_struct *new_vma)
> > > {
> > > struct anon_vma_name *anon_name = vma_anon_name(orig_vma);
> > >
> > > - if (anon_name) {
> > > - anon_vma_name_get(anon_name);
> > > - new_vma->anon_name = anon_name;
> > > - }
> > > + if (anon_name)
> > > + new_vma->anon_name = anon_vma_name_reuse(anon_name);
> > > }
> > >
> > > static inline void free_vma_anon_name(struct vm_area_struct *vma)
> > > diff --git a/mm/madvise.c b/mm/madvise.c
> > > index f81d62d8ce9b..a395884aeecb 100644
> > > --- a/mm/madvise.c
> > > +++ b/mm/madvise.c
> > > @@ -122,8 +122,7 @@ static int replace_vma_anon_name(struct vm_area_struct *vma,
> > > if (anon_vma_name_eq(orig_name, anon_name))
> > > return 0;
> > >
> > > - anon_vma_name_get(anon_name);
> > > - vma->anon_name = anon_name;
> > > + vma->anon_name = anon_vma_name_reuse(anon_name);
> > > anon_vma_name_put(orig_name);
> > >
> > > return 0;
> > > --
> > > 2.35.1.473.g83b2b277ed-goog
> >
> > --
> > Michal Hocko
> > SUSE Labs
next prev parent reply other threads:[~2022-02-23 3:02 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-22 5:40 [PATCH 1/3] mm: refactor vm_area_struct::anon_vma_name usage code Suren Baghdasaryan
2022-02-22 5:40 ` [PATCH 2/3] mm: prevent vm_area_struct::anon_name refcount saturation Suren Baghdasaryan
2022-02-22 9:17 ` Michal Hocko
2022-02-22 15:56 ` Suren Baghdasaryan
2022-02-23 3:02 ` Suren Baghdasaryan [this message]
2022-02-23 8:26 ` Michal Hocko
2022-02-22 5:40 ` [PATCH v4 3/3] mm: fix use-after-free when anon vma name is used after vma is freed Suren Baghdasaryan
2022-02-22 5:41 ` Suren Baghdasaryan
2022-02-22 8:06 ` Michal Hocko
2022-02-22 15:43 ` Suren Baghdasaryan
2022-02-23 8:55 ` Michal Hocko
2022-02-23 14:10 ` Suren Baghdasaryan
2022-02-23 15:29 ` Michal Hocko
2022-02-23 15:38 ` Suren Baghdasaryan
2022-02-22 8:51 ` [PATCH 1/3] mm: refactor vm_area_struct::anon_vma_name usage code Michal Hocko
2022-02-22 15:51 ` Suren Baghdasaryan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJuCfpFkwZAw-qcD6E5SchHNXf8MmzyWtuWaHOpFhid3m5bg8A@mail.gmail.com \
--to=surenb@google.com \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=caoxiaofeng@yulong.com \
--cc=ccross@google.com \
--cc=chris.hyser@oracle.com \
--cc=dave.hansen@intel.com \
--cc=dave@stgolabs.net \
--cc=david@redhat.com \
--cc=ebiederm@xmission.com \
--cc=gorcunov@gmail.com \
--cc=hannes@cmpxchg.org \
--cc=keescook@chromium.org \
--cc=kernel-team@android.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=legion@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=pcc@google.com \
--cc=ran.xiaokai@zte.com.cn \
--cc=sashal@kernel.org \
--cc=sumit.semwal@linaro.org \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox