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=-9.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT 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 66CACC33CB7 for ; Mon, 20 Jan 2020 07:44:07 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1F8CA2073D for ; Mon, 20 Jan 2020 07:44:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=axtens.net header.i=@axtens.net header.b="IsVuaMki" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1F8CA2073D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=axtens.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C5D196B05C2; Mon, 20 Jan 2020 02:44:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BE6B56B05C3; Mon, 20 Jan 2020 02:44:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AAE586B05C4; Mon, 20 Jan 2020 02:44:06 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0019.hostedemail.com [216.40.44.19]) by kanga.kvack.org (Postfix) with ESMTP id 8DF786B05C2 for ; Mon, 20 Jan 2020 02:44:06 -0500 (EST) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 3C8BB181AC9C6 for ; Mon, 20 Jan 2020 07:44:06 +0000 (UTC) X-FDA: 76397224092.16.bean75_23c3378fca41b X-HE-Tag: bean75_23c3378fca41b X-Filterd-Recvd-Size: 6445 Received: from mail-pf1-f196.google.com (mail-pf1-f196.google.com [209.85.210.196]) by imf26.hostedemail.com (Postfix) with ESMTP for ; Mon, 20 Jan 2020 07:44:05 +0000 (UTC) Received: by mail-pf1-f196.google.com with SMTP id z16so15433827pfk.0 for ; Sun, 19 Jan 2020 23:44:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axtens.net; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=4ceV5dzkz6HqCMW6fBoym4ypC/m9xh1QjTBMfyGPn8o=; b=IsVuaMkiPafyhTmbUmmKKq2zQ2knSaijf8xt11NZ6XL9Q4Hm1Cfdm8CztrO01x5ltK VnhPQHcNW2slNw6gRk8rL5iIUAbKO40Kuwiaqw1t/4WmuKa+tf45OOD70HBQ71fF1tLO +5Vv23deCqiMdkkxkLo3lvuCj1D8aE7yy6hs4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=4ceV5dzkz6HqCMW6fBoym4ypC/m9xh1QjTBMfyGPn8o=; b=LlKkEk7H82GWfe9c8kkRmzniaqj6ygJzStEj/EB8td2PJ1CDYv+AeYEUCm0+m7oxcL cfvP1G2cf/pdKn5kXPyJ2Bk8y/yCZ/HYkOqZ4TBd/sCq/CfaKgrNgYMBf5ZWCZoRNUGB CqGi1CXH9m3rjJWW0KbpSpiSZ8yelGCNnwe/oZEd6erIyLmn+Jo2V28ISKthNXwTcOds uB326RU8Bss8v3Ood0ntw9DZiGomL9Ml/gnRI26HSb7Tj5OJ+SetiT5EULT+wOxwBB3J V9NMKcWCVljfUTYpoGS4btgLj2TT/kF29tdvpPeKYj42FYQ1Ld1zuI694H+ydHGPojtM nRVQ== X-Gm-Message-State: APjAAAW+mG8/xNZb90tEtKun3RrDoKTbrJIZ7f//1bkUE2rB2HMPwqzs 69BypaqJaPHyFOp3hj/eIk/Uwg== X-Google-Smtp-Source: APXvYqxpn7k/Ufr5n0ApK06TsYbJxU+ior64MbZ5pNsKbxSZFpNAZBslVxeMWsQFy8/9nF92ZyhObQ== X-Received: by 2002:a63:cc4a:: with SMTP id q10mr58040093pgi.241.1579506244663; Sun, 19 Jan 2020 23:44:04 -0800 (PST) Received: from localhost (2001-44b8-1113-6700-4064-d910-a710-f29a.static.ipv6.internode.on.net. [2001:44b8:1113:6700:4064:d910:a710:f29a]) by smtp.gmail.com with ESMTPSA id y62sm40131883pfg.45.2020.01.19.23.44.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Jan 2020 23:44:04 -0800 (PST) From: Daniel Axtens To: kernel-hardening@lists.openwall.com, linux-mm@kvack.org, keescook@chromium.org Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org, Daniel Axtens Subject: [PATCH 4/5] [VERY RFC] mm: kmalloc(_node): return NULL immediately for SIZE_MAX Date: Mon, 20 Jan 2020 18:43:43 +1100 Message-Id: <20200120074344.504-5-dja@axtens.net> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200120074344.504-1-dja@axtens.net> References: <20200120074344.504-1-dja@axtens.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: kmalloc is sometimes compiled with an size that at compile time may be equal to SIZE_MAX. For example, struct_size(struct, array member, array elements) returns th= e size of a structure that has an array as the last element, containing a given number of elements, or SIZE_MAX on overflow. However, struct_size operates in (arguably) unintuitive ways at compile t= ime. Consider the following snippet: struct foo { int a; int b[0]; }; struct foo *alloc_foo(int elems) { struct foo *result; size_t size =3D struct_size(result, b, elems); if (__builtin_constant_p(size)) { BUILD_BUG_ON(size =3D=3D SIZE_MAX); } result =3D kmalloc(size, GFP_KERNEL); return result; } I expected that size would only be constant if alloc_foo() was called within that translation unit with a constant number of elements, and the compiler had decided to inline it. I'd therefore expect that 'size' is on= ly SIZE_MAX if the constant provided was a huge number. However, instead, this function hits the BUILD_BUG_ON, even if never called. include/linux/compiler.h:394:38: error: call to =E2=80=98__compiletime_as= sert_32=E2=80=99 declared with attribute error: BUILD_BUG_ON failed: size= =3D=3D SIZE_MAX This is with gcc 9.2.1, and I've also observed it with an gcc 8 series compiler. My best explanation of this is: - elems is a signed int, so a small negative number will become a very large unsigned number when cast to a size_t, leading to overflow. - Then, the only way in which size can be a constant is if we hit the overflow case, in which 'size' will be 'SIZE_MAX'. - So the compiler takes that value into the body of the if statement and blows up. But I could be totally wrong. Anyway, this is relevant to slab.h because kmalloc() and kmalloc_node() check if the supplied size is a constant and take a faster path if so. A number of callers of those functions use struct_size to determine the siz= e of a memory allocation. Therefore, at compile time, those functions will = go down the constant path, specialising for the overflow case. When my next patch is applied, gcc will then throw a warning any time kmalloc_large could be called with a SIZE_MAX size, as gcc deems SIZE_MAX to be too big an allocation. So, make functions that check __builtin_constant_p check also against SIZE_MAX in the constant path, and immediately return NULL if we hit it. This brings kmalloc() and kmalloc_node() into line with the array functio= ns kmalloc_array() and kmalloc_array_node() for the overflow case. The overa= ll compiled size change per bloat-o-meter is in the noise (a reduction of <0.01%). Signed-off-by: Daniel Axtens --- include/linux/slab.h | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/include/linux/slab.h b/include/linux/slab.h index 03a389358562..8141c6b1882a 100644 --- a/include/linux/slab.h +++ b/include/linux/slab.h @@ -544,6 +544,9 @@ static __always_inline void *kmalloc(size_t size, gfp= _t flags) #ifndef CONFIG_SLOB unsigned int index; #endif + if (unlikely(size =3D=3D SIZE_MAX)) + return NULL; + if (size > KMALLOC_MAX_CACHE_SIZE) return kmalloc_large(size, flags); #ifndef CONFIG_SLOB @@ -562,6 +565,9 @@ static __always_inline void *kmalloc(size_t size, gfp= _t flags) =20 static __always_inline void *kmalloc_node(size_t size, gfp_t flags, int = node) { + if (__builtin_constant_p(size) && size =3D=3D SIZE_MAX) + return NULL; + #ifndef CONFIG_SLOB if (__builtin_constant_p(size) && size <=3D KMALLOC_MAX_CACHE_SIZE) { --=20 2.20.1