From patchwork Wed Oct 9 14:05:59 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Al Viro X-Patchwork-Id: 11181251 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 0612B912 for ; Wed, 9 Oct 2019 14:06:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C73BC21848 for ; Wed, 9 Oct 2019 14:06:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C73BC21848 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=zeniv.linux.org.uk Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C45B28E0005; Wed, 9 Oct 2019 10:06:11 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id BF6968E0003; Wed, 9 Oct 2019 10:06:11 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B0B5C8E0005; Wed, 9 Oct 2019 10:06:11 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0059.hostedemail.com [216.40.44.59]) by kanga.kvack.org (Postfix) with ESMTP id 8F0718E0003 for ; Wed, 9 Oct 2019 10:06:11 -0400 (EDT) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 2D66B181AC9AE for ; Wed, 9 Oct 2019 14:06:11 +0000 (UTC) X-FDA: 76024420542.15.cart81_8d2fddfdb5c39 X-Spam-Summary: 1,0,0,,d41d8cd98f00b204,viro@ftp.linux.org.uk,:torvalds@linux-foundation.org:rcampbell@nvidia.com:alexander.duyck@gmail.com:longman@redhat.com:ak@linux.intel.com::linux-api@vger.kernel.org,RULES_HIT:30012:30034:30036:30051:30054:30070:30079,0,RBL:195.92.253.2:@ftp.linux.org.uk:.lbl8.mailshell.net-62.14.15.2 64.201.201.201,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fn,MSBL:0,DNSBL:neutral,Custom_rules:0:0:0,LFtime:547,LUA_SUMMARY:none X-HE-Tag: cart81_8d2fddfdb5c39 X-Filterd-Recvd-Size: 3919 Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [195.92.253.2]) by imf37.hostedemail.com (Postfix) with ESMTP for ; Wed, 9 Oct 2019 14:06:10 +0000 (UTC) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.2 #3 (Red Hat Linux)) id 1iICbH-0002Ll-NT; Wed, 09 Oct 2019 14:05:59 +0000 Date: Wed, 9 Oct 2019 15:05:59 +0100 From: Al Viro To: Linus Torvalds Cc: Ralph Campbell , Alexander Duyck , Waiman Long , Andi Kleen , linux-mm@kvack.org, linux-api@vger.kernel.org Subject: [PATCH] off-by-one in get_mempolicy(2) Message-ID: <20191009140559.GY26530@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.12.1 (2019-06-15) 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: get_mempolicy(2) and related syscalls have always passed 1 + number of bits in nodemask as maxnodes argument - see e.g. copy_nodes_to_user() and get_nodes(). Or libnuma, for the userland side - static void getpol(int *oldpolicy, struct bitmask *bmp) { if (get_mempolicy(oldpolicy, bmp->maskp, bmp->size + 1, 0, 0) < 0) numa_error("get_mempolicy"); } and similar for other syscalls. However, the check for insufficient destination size in get_mempolicy(2) used to be if (nmask != NULL && maxnode < MAX_NUMNODES) return -EINVAL; IOW, maxnode == MAX_NUMNODES (representing "MAX_NUMNODES - 1 bits") had been accepted. The reason why that hadn't messed libnuma logics used to determine the required bitmap size is that MAX_NUMNODES is always a power of 2 and the loop in libnuma is nodemask_sz = 16; do { nodemask_sz <<= 1; mask = realloc(mask, nodemask_sz / 8); if (!mask) return; } while (get_mempolicy(&pol, mask, nodemask_sz + 1, 0, 0) < 0 && errno == EINVAL && nodemask_sz < 4096*8); I.e. it's been passing 33, 65, 127, etc. until it got it large enough. That sidesteps the boundary case - we never try to pass exactly MAX_NUMNODES there. However, that has changed recently, when get_mempolicy() switched to if (nmask != NULL && maxnode < nr_node_ids) return -EINVAL; _That_ can trigger. Consider a box with nr_node_ids == 65. The first call in libnuma:set_nodemask_size() loop will pass 33 and fail, then we'll raise nodemask_sz to 64, allocate a 64bit mask and call get_mempolicy(&pol, mask, 65, 0, 0), which will succeed. OK, so we decide to use 64bit bitmaps, and subsequent getpol() will be passing 65 to get_mempolicy(2). Which is not a good idea, since kernel-side we'll get copy_nodes_to_user(nmask, 65, &nodes) And that will copy only 8 bytes out of kernel-side bitmap with 65 bits in it... IOW, that check always should had been <=, not <; it didn't matter until commit 050c17f239fd ("numa: change get_mempolicy() to use nr_node_ids instead of MAX_NUMNODES") this year. The fix is trivial - we need to make that check consistent with the code that does actual copyin/copyout. Fixes: 050c17f239fd ("numa: change get_mempolicy() to use nr_node_ids instead of MAX_NUMNODES") Signed-off-by: Al Viro Acked-by: Vlastimil Babka diff --git a/mm/mempolicy.c b/mm/mempolicy.c index 4ae967bcf954..e184df7633b0 100644 --- a/mm/mempolicy.c +++ b/mm/mempolicy.c @@ -1561,7 +1561,7 @@ static int kernel_get_mempolicy(int __user *policy, addr = untagged_addr(addr); - if (nmask != NULL && maxnode < nr_node_ids) + if (nmask != NULL && maxnode <= nr_node_ids) return -EINVAL; err = do_get_mempolicy(&pval, &nodes, addr, flags);