From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 49496C32771 for ; Wed, 15 Jan 2020 19:05:34 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1236F2084D for ; Wed, 15 Jan 2020 19:05:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1236F2084D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 954BB8E0005; Wed, 15 Jan 2020 14:05:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8DC898E0003; Wed, 15 Jan 2020 14:05:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7CBE28E0005; Wed, 15 Jan 2020 14:05:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0140.hostedemail.com [216.40.44.140]) by kanga.kvack.org (Postfix) with ESMTP id 67F3E8E0003 for ; Wed, 15 Jan 2020 14:05:33 -0500 (EST) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 27CCF282D for ; Wed, 15 Jan 2020 19:05:33 +0000 (UTC) X-FDA: 76380797346.25.show45_134d0eb7cc75c X-HE-Tag: show45_134d0eb7cc75c X-Filterd-Recvd-Size: 5294 Received: from mail-wm1-f66.google.com (mail-wm1-f66.google.com [209.85.128.66]) by imf07.hostedemail.com (Postfix) with ESMTP for ; Wed, 15 Jan 2020 19:05:32 +0000 (UTC) Received: by mail-wm1-f66.google.com with SMTP id d73so1161827wmd.1 for ; Wed, 15 Jan 2020 11:05:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Kfwb/DZbMO5EaYi5yWox5Vryq+/ETLE5snZCjP2eywQ=; b=cA2fP74+2y+LtoCrR71FqC9xR+EPe+uIQeV+ErAcGqXyGx373IbAqo6kbhO2giSZUD OFdkoluo1DBO2947pXJq2voS1mm6y6bXexIqk+8y0aeP67NvykcaUXiA8DdlhiTX/iz9 V54K/XyTmAHaQeKaXvaWm3U2YZq4ZtZcfyzV7IKili6hw6XNMiatB47R3H2ynfBdPAiv sL5vbed+mzVJ6jPO+eiDoAiTarh7AFAUXr/wsOeU7yhUOmakT5HonAB5EShgJ7rYOaRr mtj4Il4rbo08aLotiKcTprXVI0aLgLsAs993d7zI3VO8X2bawv6kcMjW1u3+5ar0FtAK wD1w== X-Gm-Message-State: APjAAAVr3LnEpgDZir5th7qs9GGHOELVVZ7NPwEcw+zGToTSwwnRL3RO ZMpC3jkT8CdQHkrTkWGuX24= X-Google-Smtp-Source: APXvYqyEayzAKYxBWIJJ/I7qBVThKmTHCboTdK3s1+ClUSqTP9KOo5fJvW8ncHfof05ooT4KueQ1Cg== X-Received: by 2002:a7b:c386:: with SMTP id s6mr1450184wmj.105.1579115131271; Wed, 15 Jan 2020 11:05:31 -0800 (PST) Received: from localhost (ip-37-188-146-105.eurotel.cz. [37.188.146.105]) by smtp.gmail.com with ESMTPSA id d14sm27023531wru.9.2020.01.15.11.05.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Jan 2020 11:05:30 -0800 (PST) Date: Wed, 15 Jan 2020 20:05:28 +0100 From: Michal Hocko To: Dmitry Vyukov Cc: Vlastimil Babka , Dan Carpenter , Andrew Morton , Lee Schermerhorn , Linux-MM , LKML , syzbot , Andrea Arcangeli , Hugh Dickins , syzkaller-bugs , Al Viro , yang.shi@linux.alibaba.com Subject: Re: [PATCH] mm/mempolicy.c: Fix out of bounds write in mpol_parse_str() Message-ID: <20200115190528.GJ19428@dhcp22.suse.cz> References: <20200115055426.vdjwvry44nfug7yy@kili.mountain> <20200115150315.GH19428@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed 15-01-20 16:14:43, Dmitry Vyukov wrote: > On Wed, Jan 15, 2020 at 4:03 PM Michal Hocko wrote: > > > > On Wed 15-01-20 13:57:47, Dmitry Vyukov wrote: > > > On Wed, Jan 15, 2020 at 1:54 PM Vlastimil Babka 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 > > > > > > > > Acked-by: Vlastimil Babka > > > > > > > > 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