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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4B100C46CD2 for ; Tue, 30 Jan 2024 18:57:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D7CD46B00AC; Tue, 30 Jan 2024 13:57:03 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D2D146B00AD; Tue, 30 Jan 2024 13:57:03 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BF51F6B00AE; Tue, 30 Jan 2024 13:57:03 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id AF84C6B00AC for ; Tue, 30 Jan 2024 13:57:03 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 51CEB140BDD for ; Tue, 30 Jan 2024 18:57:03 +0000 (UTC) X-FDA: 81736884726.17.7A1D7DF Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) by imf14.hostedemail.com (Postfix) with ESMTP id 71B8D100006 for ; Tue, 30 Jan 2024 18:57:01 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=FZ45IAeX; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf14.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.167.53 as permitted sender) smtp.mailfrom=lstoakes@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706641021; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=WnPPP9gYwbIuo1o6aZoujXAzAvI1Caar+xkvAzwhO4w=; b=fOZXC1/w7HPxv1UddeRyvfS4OkGRs6Ke5Jmt/WQbvzEl9bN1zLJQlXCkk5qNDQaK8BA/w5 xR/ekZ+vm6C7m10NFYT6mwcBz77K/OkBwkj/KSJP5TGrJPBt+RDkSLRoGt+xxSVsdGtrGu vr/rvcl8KEtAIV7C9Lpag0cN9QnskmU= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=FZ45IAeX; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf14.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.167.53 as permitted sender) smtp.mailfrom=lstoakes@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706641021; a=rsa-sha256; cv=none; b=snzCHV7U/UIBEANPr2ZCLrCw9eEAfeaCimtaWHLYad5D7mdkh2QXwU7HqwYg8bHgriNyJc c54WKX+32CrDY/1MxTxxKabn/RABtbZkpZq8Gi+SCVqFbMEWUFdl2xO/QOhx18Zvjw6O41 lrdM2O+DaIGx8vquARtL1F0tqmBSGA8= Received: by mail-lf1-f53.google.com with SMTP id 2adb3069b0e04-51031ae95a1so4245457e87.0 for ; Tue, 30 Jan 2024 10:57:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706641020; x=1707245820; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=WnPPP9gYwbIuo1o6aZoujXAzAvI1Caar+xkvAzwhO4w=; b=FZ45IAeXuK7QiIG2R7h34TxdmE4DbIbB24gkf3thh+3yjpv0WzaI7Y8bEre+BaJ4kg nxOc0yLy0aQDAKae+8csuLOpJg5mvQujgBw1PYh/CZWGIbdD2iO8cvlDwFvx/4fLwIIT zKGlEpsi9YLlqpfDDyKsL5hrJLg43DsnVeBqNHy+T+xsI99QAfezTaWup+oUf7lIAPa5 GpuAlVuwqnc3DJCK4Zlp66ANm4nw7P+bbaBPptH++lQbIA+obCXqoOKvkG8sMvIGgv5y 5bHuy4StEVfEAa7IXhpqNgcsTgUbgElNPiQAIm9v8J3pGG5PZ+ngaymDrz4NRRYqnR7X Lqqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706641020; x=1707245820; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=WnPPP9gYwbIuo1o6aZoujXAzAvI1Caar+xkvAzwhO4w=; b=oy0UN92aCfDOj3/DhrtXIUbV4rM+Ld6028fSel7uimJy1rAUkHw97gQqn9PA/WBA3m l1AMrZhXpdCNSz9P/Yy1jd2MIHcsGnFfaM5TWfTNcGHByF7gkZ6Vw+y8KURZ/dp/os92 oexB5PAQrN9R1A9hHZJaS25ai6p2kktLZTn7ea49euBeEtXkuMX/nwBpy8v9E99HepP2 YdcXoTRyH1O4Bp3gtE7nBg68Y8sCeXd4BuV1yMwyaQV9ZXvT1jzOO1EmG0RCC2LadVtK jZ41+13VMJQ5nj7MHPMsD8iukXD1ortwCJuk09Q5a/tOilHB8IfUS3CsZIoNdSbnZq68 ZATQ== X-Gm-Message-State: AOJu0Yx4oZh6cGJM+NI3uZ/SGiYGL8/3ng4DK6U7DxOIkItPDs/s6LDD lvabm6LJ9zE7Yn9BOXqiX3alzyoZDxr/k0CcnNVw4a3i4hC3L/qiQv9pRwkQ X-Google-Smtp-Source: AGHT+IE3xr4rtv5MU4W4Zo8/7ZFviWGE4HTIZshULPmezl6/XqzcQv1JPSSdasRHlznLHelOdXXGkA== X-Received: by 2002:a05:6512:6d0:b0:511:17d2:8bc0 with SMTP id u16-20020a05651206d000b0051117d28bc0mr3046779lff.41.1706641019564; Tue, 30 Jan 2024 10:56:59 -0800 (PST) Received: from localhost ([2a00:23cc:d20f:ba01:bb66:f8b2:a0e8:6447]) by smtp.gmail.com with ESMTPSA id n4-20020a5d4c44000000b0033aeda49732sm6045845wrt.33.2024.01.30.10.56.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Jan 2024 10:56:58 -0800 (PST) Date: Tue, 30 Jan 2024 18:56:57 +0000 From: Lorenzo Stoakes To: Kees Cook Cc: linux-hardening@vger.kernel.org, Andrew Morton , Uladzislau Rezki , Christoph Hellwig , linux-mm@kvack.org, "Gustavo A. R. Silva" , Bill Wendling , Justin Stitt , linux-kernel@vger.kernel.org Subject: Re: [PATCH 78/82] mm/vmalloc: Refactor intentional wrap-around test Message-ID: <0e101d46-70ea-4577-8de5-bfce23a1e9bd@lucifer.local> References: <20240122235208.work.748-kees@kernel.org> <20240123002814.1396804-78-keescook@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240123002814.1396804-78-keescook@chromium.org> X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 71B8D100006 X-Stat-Signature: mq7cb4kn4k9rqiixu4q5qo1oz9epm9fe X-Rspam-User: X-HE-Tag: 1706641021-549620 X-HE-Meta: U2FsdGVkX19HkYrmX5GgYj59kOROYMqVfcv2EUgH+/7TnrErjtChlAyB4a7hPlD/pL7tFkuvAFMiEnSti4fcP7dOL7DZRLhdIlAXGynIUIbB9EwREvCx/OZKQPO1iTWhFQ9N7Sgtb81yU7JjoZIQu6V42Q786ls1+t7DAYkgbvGPkLEo10gnMqNx3Wq7wg9JaPrp5tt4uNu/rmAHQXk3ULgr9GDzom7LUhobj2++Frt5xbrjmLKEiH5KuGdsx+cCJOW3qL+ditj/foQgdTJWXq74FUo9xwThT9humq5gwGJdF73gHWqkBG9maOgNaxrAQjZishn3MiWOVchvqOeGEZpfbHHABrOUzFi4dTd2arcu2Wx2MYyOCFDvL2PESagASimMXogC0xcOSAW3z2JwQSAqPFToTL4trvNBxFshQS3+rsCW221n6WCTQVTII2qUNXuqAZGWfvwHckc/t5IRddBcDSlq3ROIlzaj3Cwdhvl/wENNDJJl0R0Ud5In7oERqJFU0sPMoVbHPwA/SlB5haY+4SGtuXJxi0v/rbptk3T+REC/zoT9Iq4N0EYq5dK89u1AbydRK42X+DFCK2dX2xs2I+jbpI9zYo4y7Ns6vnl93sbWNB/UaM8B4RqkpLGsxHtjt3aBzxgdqX0m6cEFkGCO0jMFvo3BqvCzNzLNxT2ppgsTqceKaiPECJsOLL/+oZL70O/lI9cewwZX4MT7f7gPvzJEabxP7r6CNHA0urs0bvEsOr34s8yX7N9OkkFCc/O+HFkEXT6PdKe13DwVe4gsbKKHyuOZJPq7kN5e1ew7HL4UIrrxaxQGJ9YocmrK8z0T86lWkvDOzbIxogDbP65imuIt19XWoasma5u21V7LDfYW0LL8AKMSwdGmH+TFj6BqQSxZLJW4zrZ4xsELbFD+v6XHcMcHtwt0QKgG+EloNQcS4ThUJj+OunhYawJ9ZZhIAsUXGfHNrfTmp97 jGHj9fci DJS6+mkm8scJstk5YekqnuuyVxhvjVTAStYalgAmWfaitIO98aEMza+V6Ie4pQ9QTm8Bsw7FwUCvQ8JVUFBODvlWBy2l5896/aJF5iq7HnRBglEbndh683QTsavhNh9lnrANrHODcLMazPoptZbQaH9/mW3D+DH5HewIzDBhl5Vp5+jA22YcYQIEdhnSgoB2NHilfNuguC9GCUBiTNiV0LeCYyyW1LI1hpVivYaJ5I0Pf39V5jBt+YHUZK81NfNFtpcDfe+6B3rGAUqB2hQwqmmSNeByIxX7UbKgFZCtNb3rhZxBwpNSjdXdRve8cPLS38e05NVgE5WXB+L7kQr3srV/po2UlvZCT+TwcPLlQSWkXouIZMjNxJhL2XSGXTp+Q9TZWzzD72ypOfJ1NpU3I+Tm/4gktK4rc23eY8fRNhkQJSVIF25PZqI18RLgYTIa+gkjD43DCnqhK7UqoItTqyf+WEla0p7xsqV9MR2wNYPx/0o9Ht9F1liCi+G/Tnt3eBWagiqMpdwX19M4AUtCcghF7f08T9kfh8H+DzhP1UKbbNPGn+dNrKYOEMzu2AtkTtkLiKNOC0UwrUfBRqw7tENi6eZrVwizbcc7D7Q2mAsyxBsvERF+IEESlhmnK9jYLNp0TjJppnXKlsYpvhGtERyoNEsRYG/Mz9vydj4F9KDVKle0tNug31tj9W5ZZUoNGlkxd 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: List-Subscribe: List-Unsubscribe: On Mon, Jan 22, 2024 at 04:27:53PM -0800, Kees Cook wrote: > In an effort to separate intentional arithmetic wrap-around from > unexpected wrap-around, we need to refactor places that depend on this > kind of math. One of the most common code patterns of this is: > > VAR + value < VAR > > Notably, this is considered "undefined behavior" for signed and pointer > types, which the kernel works around by using the -fno-strict-overflow > option in the build[1] (which used to just be -fwrapv). Regardless, we > want to get the kernel source to the position where we can meaningfully > instrument arithmetic wrap-around conditions and catch them when they > are unexpected, regardless of whether they are signed[2], unsigned[3], > or pointer[4] types. > > Refactor open-coded wrap-around addition test to use add_would_overflow(). > This paves the way to enabling the wrap-around sanitizers in the future. > > Link: https://git.kernel.org/linus/68df3755e383e6fecf2354a67b08f92f18536594 [1] > Link: https://github.com/KSPP/linux/issues/26 [2] > Link: https://github.com/KSPP/linux/issues/27 [3] > Link: https://github.com/KSPP/linux/issues/344 [4] > Cc: Andrew Morton > Cc: Uladzislau Rezki > Cc: Christoph Hellwig > Cc: Lorenzo Stoakes > Cc: linux-mm@kvack.org > Signed-off-by: Kees Cook > --- > mm/vmalloc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index 7932ac99e9d3..3d73f2ac6957 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -3750,7 +3750,7 @@ long vread_iter(struct iov_iter *iter, const char *addr, size_t count) > addr = kasan_reset_tag(addr); > > /* Don't allow overflow */ > - if ((unsigned long) addr + count < count) > + if (add_would_overflow(count, (unsigned long)addr)) > count = -(unsigned long) addr; > > remains = count; > -- > 2.34.1 > Looks good to me, Reviewed-by: Lorenzo Stoakes