Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp373590imm; Thu, 13 Sep 2018 01:02:37 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZpaD4yofJSwIC+ou6GoM8Xbwt442Y9akEfC3EHYHnm4FhKnCs6tsaY9pQLkggO6J0NIrDr X-Received: by 2002:a62:c60e:: with SMTP id m14-v6mr6276508pfg.40.1536825757145; Thu, 13 Sep 2018 01:02:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536825757; cv=none; d=google.com; s=arc-20160816; b=kEB0mJCALK5r42w1OT8QS2fViXO+f02O+9/T/MgOILTfDD8pRJU3Ys+O3Q5RFrmfN0 8Ki9heMS2+MMO0gIv8d/O8+uqS+YmqxG+x6nza/xr6j4WHAnC3HAqUp4F+ax3iYgc/J+ S5z3x53augBE0ukmU/XxR1vKbzPfkyVvmm3YiscNsmND3IYnHF9PnU48Ig4tVlLK3sRY O7OqYM70ZIpY8F0WAk1CE7p05WMLUrcARHZ+FoHWH1QdY2/7E1fgE5NAtigXCbB+KvLf rFhyidAeEti0HpziXkDoAEhgvfCW+0eI4yc76FzKeW6eNycqJ48yhRq46+zurfAh2JoP m6CQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature; bh=cz17QLutfTFy0OH0lAS7ooB9qZwadL6Dr6fDuVfdDiU=; b=isDhDMZ4XBzVg6AP/o69+vURfTP7f4PYjJUDC64ruSUtDd56ivvFo2r/TDubrZz3Yp wBAahxjQP6rDfqBc9HNIA/q7b70sxZm0qxYox13NcGGnsrpJh3TwYTyPSWtCxkKr3uQs 1cv2p9tSiKP5pV+d7B6EkmKw3nJQZp3INzu07Gj66/eVem2dFGOlYjRO/xQbgOpHXH9t kOf+GyxItBv9wyzL/DUHBAzU1qJlzkxEMYPV0uk/jZ4gO768yfx01JotnGEmgOeKS81y /4IyIBtWjoqV9dDOn9b6UM0R7SfHAqr0KMdpmU4lCMCJ6V4RuKtuyq2KMLAkafbEBhyE rHzA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="ncSUx/CA"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n24-v6si3506539pgj.14.2018.09.13.01.02.19; Thu, 13 Sep 2018 01:02:37 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="ncSUx/CA"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727649AbeIMNK2 (ORCPT + 99 others); Thu, 13 Sep 2018 09:10:28 -0400 Received: from mail-it0-f67.google.com ([209.85.214.67]:35433 "EHLO mail-it0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726751AbeIMNK2 (ORCPT ); Thu, 13 Sep 2018 09:10:28 -0400 Received: by mail-it0-f67.google.com with SMTP id 139-v6so6649711itf.0 for ; Thu, 13 Sep 2018 01:02:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cz17QLutfTFy0OH0lAS7ooB9qZwadL6Dr6fDuVfdDiU=; b=ncSUx/CAJYyX9EuAtNg8VF8LZXyG83naV3fVYTCsTNdvtmkJ8TB/kUgxTEye0AZ+Rf /QESKe1iE9+jbyS9RAaARso8S/2mL/RXNP/BlWbEqfS7+MbT4X8DxP16XN0VYHEh0RSj FkRn79KoXR86G4+YViLLbiZSjwH7hfH8OxiC1h4uTDf4UoVWRjntivvaE9MN5cP0Q9tE Nvz38z+P2MxF7TSLG7vQ+kEs4Q186+TtDoGc4A+ny8+Cf8rS/NJUDW234uczm7gPfl5r zGUL48GAGaQT2QW5+/EjAf4JZ7SwG3YhEpfHmuAxXNw2HqD1gfUk1JWve2zglIcd+OYA 6oVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cz17QLutfTFy0OH0lAS7ooB9qZwadL6Dr6fDuVfdDiU=; b=rdlCcD9mFnDSlDonGZGzMQ+Wvv6U3WBXLnd6fSwD2L8QeMnL56nE59Q+cbCrFCNmR1 b7YjHVSuw+7ashteRoM9UgPjWOhL4iY1QBzqzrY9UnUaYwpZMaBzBQT8nq5JjCBadQzv Mal8yRLpz3GEI9Hn2HvlF6Tj9o/eZFwacQHT9w5YBMGqwiS2341mqVJQk2R6jPu4c9F8 29+ka/9PnvIhQiRL0D8QpI5q1H0lcaaAWmuEgQlkF6gQdvexyGQrx2MFnoK+49NA/vhi nHdjrO4DH2SefZDPzoyE5RkxKQIil0ntv12tqzqbz/lH52K2/6dt0c/P9ddXGAfHPDGD TGeg== X-Gm-Message-State: APzg51AtCmmVrNQqHDNnOdIodJDE5PtC/wLCTozp6Q5KY9W8puVO2mh2 eq7l+aJ194ydIOB2lNygzdg6RaAKAnZCBRgqRZxTpJ9QfHI= X-Received: by 2002:a02:4009:: with SMTP id n9-v6mr5608804jaa.19.1536825728115; Thu, 13 Sep 2018 01:02:08 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:5942:0:0:0:0:0 with HTTP; Thu, 13 Sep 2018 01:01:47 -0700 (PDT) In-Reply-To: References: <000000000000038dab0575476b73@google.com> From: Dmitry Vyukov Date: Thu, 13 Sep 2018 10:01:47 +0200 Message-ID: Subject: Re: [PATCH] selinux: Add __GFP_NOWARN to allocation at str_read() To: Paul Moore Cc: Tetsuo Handa , SELinux , syzbot+ac488b9811036cea7ea0@syzkaller.appspotmail.com, Eric Paris , LKML , peter.enderborg@sony.com, Stephen Smalley , syzkaller-bugs Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 13, 2018 at 5:02 AM, Paul Moore wrote: > On Fri, Sep 7, 2018 at 12:43 PM Tetsuo Handa > wrote: >> syzbot is hitting warning at str_read() [1] because len parameter can >> become larger than KMALLOC_MAX_SIZE. We don't need to emit warning for >> this case. >> >> [1] https://syzkaller.appspot.com/bug?id=7f2f5aad79ea8663c296a2eedb81978401a908f0 >> >> Signed-off-by: Tetsuo Handa >> Reported-by: syzbot >> --- >> security/selinux/ss/policydb.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/security/selinux/ss/policydb.c b/security/selinux/ss/policydb.c >> index e9394e7..f4eadd3 100644 >> --- a/security/selinux/ss/policydb.c >> +++ b/security/selinux/ss/policydb.c >> @@ -1101,7 +1101,7 @@ static int str_read(char **strp, gfp_t flags, void *fp, u32 len) >> if ((len == 0) || (len == (u32)-1)) >> return -EINVAL; >> >> - str = kmalloc(len + 1, flags); >> + str = kmalloc(len + 1, flags | __GFP_NOWARN); >> if (!str) >> return -ENOMEM; > > Thanks for the patch. > > My eyes are starting to glaze over a bit chasing down all of the > different kmalloc() code paths trying to ensure that this always does > the right thing based on size of the allocation and the different slab > allocators ... are we sure that this will always return NULL when (len > + 1) is greater than KMALLOC_MAX_SIZE for the different slab allocator > configurations? Yes, it's the blessed way to do it. We have lots of similar cases: https://elixir.bootlin.com/linux/v4.19-rc3/ident/__GFP_NOWARN