linux-kernel - Re: [PATCH 2/3] mm: prevent vm_area_struct::anon

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 23 Feb 2022 09:26:02 +0100
From:   Michal Hocko <mhocko@...e.com>
To:     Suren Baghdasaryan <surenb@...gle.com>
Cc:     akpm@...ux-foundation.org, ccross@...gle.com,
        sumit.semwal@...aro.org, dave.hansen@...el.com,
        keescook@...omium.org, willy@...radead.org,
        kirill.shutemov@...ux.intel.com, vbabka@...e.cz,
        hannes@...xchg.org, ebiederm@...ssion.com, brauner@...nel.org,
        legion@...nel.org, ran.xiaokai@....com.cn, sashal@...nel.org,
        chris.hyser@...cle.com, dave@...olabs.net, pcc@...gle.com,
        caoxiaofeng@...ong.com, david@...hat.com, gorcunov@...il.com,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        kernel-team@...roid.com
Subject: Re: [PATCH 2/3] mm: prevent vm_area_struct::anon_name refcount
 saturation

On Tue 22-02-22 19:02:08, Suren Baghdasaryan wrote:
> On Tue, Feb 22, 2022 at 7:56 AM Suren Baghdasaryan <surenb@...gle.com> wrote:
> >
> > On Tue, Feb 22, 2022 at 1:17 AM Michal Hocko <mhocko@...e.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?

Yeah, I guess this should be the message the changelog should be
sending.
-- 
Michal Hocko
SUSE Labs