On Wed 15-01-20 16:14:43, Dmitry Vyukov wrote:
> On Wed, Jan 15, 2020 at 4:03 PM Michal Hocko <mhocko@xxxxxxxxxx> wrote:
> >
> > On Wed 15-01-20 13:57:47, Dmitry Vyukov wrote:
> > > On Wed, Jan 15, 2020 at 1:54 PM Vlastimil Babka <vbabka@xxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxx
> > > > > Fixes: 095f1fc4ebf3 ("mempolicy: rework shmem mpol parsing and display")
> > > > > Signed-off-by: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
> > > >
> > > > Acked-by: Vlastimil Babka <vbabka@xxxxxxx>
> > > >
> > > > 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.
That's bad!
> Most kmalloc/vmalloc's are not accounted and can be abused.
Many of those should be bound to some objects and if those are directly
controllable by userspace then we should account at least. And if they
are not bound to a process life time then restricted.
> Is tmpfs even worse than these?
Well, tmpfs is accounted and restricted by memcg at least. The problem
is that it the memory is not really bound to a process life time which
makes it effectively unreclaimable once the swap space is depleted.
Still bad.
--
Michal Hocko
SUSE Labs
