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=-11.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no 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 6C3BCC33CB1 for ; Thu, 16 Jan 2020 10:13:23 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1D86B206B7 for ; Thu, 16 Jan 2020 10:13:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="jn4zIb4q" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1D86B206B7 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id AF31D8E0060; Thu, 16 Jan 2020 05:13:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A7F198E003F; Thu, 16 Jan 2020 05:13:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 91E1B8E0060; Thu, 16 Jan 2020 05:13:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0161.hostedemail.com [216.40.44.161]) by kanga.kvack.org (Postfix) with ESMTP id 758A78E003F for ; Thu, 16 Jan 2020 05:13:22 -0500 (EST) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 03D6C33CD for ; Thu, 16 Jan 2020 10:13:22 +0000 (UTC) X-FDA: 76383085044.10.hose98_578b91d76d45b X-HE-Tag: hose98_578b91d76d45b X-Filterd-Recvd-Size: 7803 Received: from mail-qt1-f194.google.com (mail-qt1-f194.google.com [209.85.160.194]) by imf20.hostedemail.com (Postfix) with ESMTP for ; Thu, 16 Jan 2020 10:13:21 +0000 (UTC) Received: by mail-qt1-f194.google.com with SMTP id e5so18398190qtm.6 for ; Thu, 16 Jan 2020 02:13:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1rX5IkiB8JnoTfZs5uAlFbe8tyhYqjCAyIiplOz/1Kc=; b=jn4zIb4qAGDMK7he3rujwEt2kFJ8nh+3qcTL0IeX2mGtII77ctTbqQTL3Xz/ggwYSL Yng2Dxnvx7bk+3yuD5hsbwo5MFrQVRsON277YPGXWsnXc4FKqRJcqSiKvvdrHACYMX8W 9iRegSAmGeDWiHdc+scR2sDX2iG+vNWmo4b4dlj9RzHNI7xNhoatHVWUdq8DpmTRytjy nQ3QPTIE7G/ps37AYWdftpV5HecE/PWBcXqa02RV9osZPNJM9g1fKDg68UxWkNO54hAs c6MfUGD/26SEgbClZDD18lcCIKAdvv1d7D8ad4iqo+m05iuA7pQi3TBtI0Bl54FwOm2e gxag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1rX5IkiB8JnoTfZs5uAlFbe8tyhYqjCAyIiplOz/1Kc=; b=BRMQNWc2NDSMqRkGybr1H9zmrOIKJok15mSQCJnk8QVJRxUE5KyaiMVnI744eQsRNV Pfrh/nV9IEAjPH7knnLmC1Zs+BExygzIGp9+Z9Qkv/z5qzgD304DwAY4UHtrJEg6DbZH 9DhsJGKuLiieBig+aupdayNmaBAJZyFzb0p4fJ9k1cL3Nl0BAoYC8uiQhbw70OM2IWX8 v+cXhjap99RNGtRusLqE9O1PLX/QYZexeyTx69O5q9C9yi0D4pOeVpVeDfXULcJGxEWm 2azwcslP9xKGoXcpnOSOw2H/AWRcF0zw3Ikp4rI4Z9lwM9+San8dbEr19FFonNFdwyvr MIZQ== X-Gm-Message-State: APjAAAXOkVxEarOjTkXCJc55c5P6xkK0DVToL4Hph0QUPL3NKAKykHSO z1dkeurPo5S5SA68OBVllkc+R85BIOztlSbItAyJDQ== X-Google-Smtp-Source: APXvYqx4WBtKtL6XktEWiHiyq3Ao2I2Zn09FzikCu1MvcM716Qphn9AqdQAyZQmvqvdhK27tPjIyTZPcA0jsdbSBTKs= X-Received: by 2002:ac8:24c1:: with SMTP id t1mr1544540qtt.257.1579169600719; Thu, 16 Jan 2020 02:13:20 -0800 (PST) MIME-Version: 1.0 References: <20200115055426.vdjwvry44nfug7yy@kili.mountain> <20200115150315.GH19428@dhcp22.suse.cz> <20200115190528.GJ19428@dhcp22.suse.cz> <20200116073922.GL19428@dhcp22.suse.cz> In-Reply-To: <20200116073922.GL19428@dhcp22.suse.cz> From: Dmitry Vyukov Date: Thu, 16 Jan 2020 11:13:09 +0100 Message-ID: Subject: Re: [PATCH] mm/mempolicy.c: Fix out of bounds write in mpol_parse_str() To: Michal Hocko 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 Content-Type: text/plain; charset="UTF-8" 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 Thu, Jan 16, 2020 at 8:39 AM Michal Hocko 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. > > > > I see you actually added one GFP_ACCOUNT in netfilter in "netfilter: > > x_tables: do not fail xt_alloc_table_info too easilly". But it seems > > there are more: > > > > $ grep vmalloc\( net/netfilter/*.c > > net/netfilter/nf_tables_api.c: return kvmalloc(alloc, GFP_KERNEL); > > net/netfilter/x_tables.c: xt[af].compat_tab = vmalloc(mem); > > net/netfilter/x_tables.c: mem = vmalloc(len); > > net/netfilter/x_tables.c: info = kvmalloc(sz, GFP_KERNEL_ACCOUNT); > > net/netfilter/xt_hashlimit.c: /* FIXME: don't use vmalloc() here or > > anywhere else -HW */ > > net/netfilter/xt_hashlimit.c: hinfo = vmalloc(struct_size(hinfo, hash, size)); > > > > These are not bound to processes/threads as namespaces are orthogonal to tasks. > > I cannot really comment on those. This is for networking people to > examine and find out whether they allow an untrusted user to runaway. Unless I am missing an elephant in this whole picture, kernel code contains 20K+ unaccounted allocations and if I am not mistaken few of them were audited and are intentionally unaccounted rather than unaccounted just because it's the default. So if we want DoS protection, it's really for every kernel developer/maintainer to audit and fix these allocation sites. And since we have a unikernel, a single unaccounted allocation may compromise the whole kernel. I assume we would need something like GFP_UNACCOUNTED to mark audited allocations that don't need accounting and then slowly reduce number of allocations without both ACCOUNTED and UNACCOUNTED. > > Somebody told me that it's not good to use GFP_ACCOUNT if the > > allocation is not tied to the lifetime of the process. Is it still > > true? > > Those are more tricky. Mostly because there is no way to reclaim the > memory once the hard limit is hit. Even the memcg oom killer will not > help much. So a care should be taken when adding GFP_ACCOUNT for those. > On the other hand it would prevent an unbounded allocations at least > so the DoS would be reduced to the hard limited memcg. What exactly is this care in practice? It seems that in a148ce15375fc664ad64762c751c0c2aecb2cafe you just added it and the allocation is not tied to the process. At least I don't see any explanation as to why that one is safe, while accounting other similar allocation is not...