All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Vyukov <dvyukov@google.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Vlastimil Babka <vbabka@suse.cz>,
	Dan Carpenter <dan.carpenter@oracle.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Lee Schermerhorn <lee.schermerhorn@hp.com>,
	Linux-MM <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	syzbot <syzbot+e64a13c5369a194d67df@syzkaller.appspotmail.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Hugh Dickins <hughd@google.com>,
	syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	yang.shi@linux.alibaba.com
Subject: Re: [PATCH] mm/mempolicy.c: Fix out of bounds write in mpol_parse_str()
Date: Wed, 15 Jan 2020 16:14:43 +0100	[thread overview]
Message-ID: <CACT4Y+Z6xW130JGcZE9X7wDCLamJA_s-STs2imnmW29SzQ-NyQ@mail.gmail.com> (raw)
In-Reply-To: <20200115150315.GH19428@dhcp22.suse.cz>

On Wed, Jan 15, 2020 at 4:03 PM Michal Hocko <mhocko@kernel.org> wrote:
>
> On Wed 15-01-20 13:57:47, Dmitry Vyukov wrote:
> > On Wed, Jan 15, 2020 at 1:54 PM Vlastimil Babka <vbabka@suse.cz> wrote:
> > >
> > > On 1/15/20 6:54 AM, Dan Carpenter wrote:
> > > > What we are trying to do is change the '=' character to a NUL terminator
> > > > and then at the end of the function we restore it back to an '='.  The
> > > > problem is there are two error paths where we jump to the end of the
> > > > function before we have replaced the '=' with NUL.  We end up putting
> > > > the '=' in the wrong place (possibly one element before the start of
> > > > the buffer).
> > >
> > > Bleh.
> > >
> > > > Reported-by: syzbot+e64a13c5369a194d67df@syzkaller.appspotmail.com
> > > > Fixes: 095f1fc4ebf3 ("mempolicy: rework shmem mpol parsing and display")
> > > > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> > >
> > > Acked-by: Vlastimil Babka <vbabka@suse.cz>
> > >
> > > CC stable perhaps? Can this (tmpfs mount options parsing AFAICS?) become
> > > part of unprivileged operation in some scenarios?
> >
> > Yes, tmpfs can be mounted by any user inside of a user namespace.
>
> Huh, is there any restriction though? It is certainly not nice to have
> an arbitrary memory allocated without a way of reclaiming it and OOM
> killer wouldn't help for shmem.

The last time I checked there were hundreds of ways to allocate
arbitrary amounts of memory without any restrictions by any user. The
example at hand was setting up GB-sized netfilter tables in netns
under userns. It's not subject to ulimit/memcg. Most kmalloc/vmalloc's
are not accounted and can be abused. Is tmpfs even worse than these?

  reply	other threads:[~2020-01-15 15:14 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-15  2:24 KASAN: slab-out-of-bounds Write in mpol_parse_str syzbot
2020-01-15  2:24 ` syzbot
2020-01-15  5:54 ` [PATCH] mm/mempolicy.c: Fix out of bounds write in mpol_parse_str() Dan Carpenter
2020-01-15 12:54   ` Vlastimil Babka
2020-01-15 12:57     ` Dmitry Vyukov
2020-01-15 12:57       ` Dmitry Vyukov
2020-01-15 15:03       ` Michal Hocko
2020-01-15 15:14         ` Dmitry Vyukov [this message]
2020-01-15 15:14           ` Dmitry Vyukov
2020-01-15 19:05           ` Michal Hocko
2020-01-16  5:41             ` Dmitry Vyukov
2020-01-16  5:41               ` Dmitry Vyukov
2020-01-16  7:39               ` Michal Hocko
2020-01-16 10:13                 ` Dmitry Vyukov
2020-01-16 10:13                   ` Dmitry Vyukov
2020-01-16 11:51                   ` Michal Hocko
2020-01-16 12:41                     ` Dmitry Vyukov
2020-01-16 12:41                       ` Dmitry Vyukov
2020-01-16 14:05                       ` Michal Hocko

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=CACT4Y+Z6xW130JGcZE9X7wDCLamJA_s-STs2imnmW29SzQ-NyQ@mail.gmail.com \
    --to=dvyukov@google.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=dan.carpenter@oracle.com \
    --cc=hughd@google.com \
    --cc=lee.schermerhorn@hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=syzbot+e64a13c5369a194d67df@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=vbabka@suse.cz \
    --cc=viro@zeniv.linux.org.uk \
    --cc=yang.shi@linux.alibaba.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.