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 D43DDC46CD2 for ; Tue, 30 Jan 2024 18:56:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6C6FB6B00AA; Tue, 30 Jan 2024 13:56:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 675A86B00AB; Tue, 30 Jan 2024 13:56:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 53D5C6B00AC; Tue, 30 Jan 2024 13:56:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 427156B00AA for ; Tue, 30 Jan 2024 13:56:04 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 1A2F6C0231 for ; Tue, 30 Jan 2024 18:56:04 +0000 (UTC) X-FDA: 81736882248.02.609E6ED Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) by imf16.hostedemail.com (Postfix) with ESMTP id 2319E18000C for ; Tue, 30 Jan 2024 18:56:00 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="PeP/AEFe"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf16.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.167.46 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=1706640961; 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=m5T7oVWNTbzcJm5kGNb2xtTeTLeD9NEFmJv4kRyhpmo=; b=DiCg+JElBhIGLbgD0ZWClzEx9O4TETQoFw9kPfO9b1jDzNkPQjAH+gsSOq4wyS/Kfr6Q2g JpeMB9+61K3w+9Eb5tufQqgzoBSEke31ee0jbZjPOQslLuZvxqWCOAB+ABtDOz3mB26ep/ Sm30Mb1B6GytkXRFNhcX5dDaQBfQyfc= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="PeP/AEFe"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf16.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.167.46 as permitted sender) smtp.mailfrom=lstoakes@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706640961; a=rsa-sha256; cv=none; b=Zqkc7PN9WRt6l4lMXt8DSIeiD8eM/wv4Nt+2qjeNOLrUbC9lwwofP3EAndAOaVMbXGOYiA JApf604fxqTQ4eEd2MighpjZNIbzjZRSWmBLRqzbd5a+qUA5TJnhcQVXrhoCHa5pKVazzT FLizpGV+a7Hafa/Gj4V94mNlelWcV2Y= Received: by mail-lf1-f46.google.com with SMTP id 2adb3069b0e04-5100cb238bcso7838493e87.3 for ; Tue, 30 Jan 2024 10:56:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706640959; x=1707245759; 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=m5T7oVWNTbzcJm5kGNb2xtTeTLeD9NEFmJv4kRyhpmo=; b=PeP/AEFeBG9a9B++FwJYnMJj4VIX91ffmSEOZXScbPP9N1TqJtC/pFmjIhWu9K9VAp oBlE9Aj/IbdL7RYNviAJggdLja5RW4E36w1KkGTR1u396CIub6/Mu5CKXLQzi9EoAlB8 K6r4k2YROABiUkHMLVjGdW7YbbWPmxRRMVV3D9NIIMWcV6qax0NyHRCz2SnZsetlErCX vuJ22pLUinUi8ZmAnN5zjycfXYUDqx18dYJ214wvARwB/EDu9o2xMYyVB2XEDpawVbQH rTLE28omAv+RTT8pAxKRaH+ovCRbTaJzsj6Yyf1j1BzoJgQyzHp81CgwjqWRZSeQfAIe XoVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706640959; x=1707245759; 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=m5T7oVWNTbzcJm5kGNb2xtTeTLeD9NEFmJv4kRyhpmo=; b=KgfPUhIXs0Q0j9JcrwhFB2ewJZkowaQV+4e2C90Nk/6uPwZSKdtFhOM5uVWuUwciAb r8fjjxYY9TDukgrn5HBjyQqm2SpIaGExqKB7Xo44Jnd4NNnUHG94qozCHO9rhkJxeGFj yWf++sJMTaAIQ1kN83acV+IFuUSpY38xpqFEjEiFdpkpa1OgOrwKfzRDNPyCNZ/lCYrz 66M2ZjSs3CrnxKGRo50DZG+nEg4WLov8C+nRhrW+mhsMi+owZL+T8AosF0FDWK2LKP+e OD3gJxsLLEw1LV+qUJLduFD1h0fPYWqXX03A6MULZE0qBlHf1SyQ28hsTt9qtDKJmSb4 sE9g== X-Gm-Message-State: AOJu0YxE0x6M08ggu1nHiH5txe7uQDbWQzQjA6+Q+6iRSdI/PqyX4IDW rvLwLqKXrHiotz1YEEvKPevW6HcS11nmJCWHcmxd7ScBKxWVF/Zp X-Google-Smtp-Source: AGHT+IHHN9DiBk7/w48kKNwAmCfjXzBDMBPMseu8RFO/EHjOhrDkATiEM32qj1bBwtRAibpOMfBYcQ== X-Received: by 2002:ac2:4208:0:b0:510:293e:83b with SMTP id y8-20020ac24208000000b00510293e083bmr5855937lfh.18.1706640959128; Tue, 30 Jan 2024 10:55:59 -0800 (PST) Received: from localhost ([2a00:23cc:d20f:ba01:bb66:f8b2:a0e8:6447]) by smtp.gmail.com with ESMTPSA id t20-20020a05600c199400b0040ef5f22710sm7708532wmq.4.2024.01.30.10.55.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Jan 2024 10:55:58 -0800 (PST) Date: Tue, 30 Jan 2024 18:55: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 33/82] mm/vmalloc: Refactor intentional wrap-around calculation Message-ID: <24526e13-2df6-47ea-865f-b5a5594bc024@lucifer.local> References: <20240122235208.work.748-kees@kernel.org> <20240123002814.1396804-33-keescook@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240123002814.1396804-33-keescook@chromium.org> X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 2319E18000C X-Stat-Signature: 391ny86etofy4z9ft9d4mds6tjmjuoaa X-HE-Tag: 1706640960-213584 X-HE-Meta: U2FsdGVkX19QBxAYXqVSwvfj0QHlshYhpsGgbYwXTlOPvjDA3dYJLCMo3eJxuSNHtmQp+dZI//4enxgP+QYWtP3VyM/6u7EIpIpXpriNYgFwan38PX/Xl4mp4BCF7bBY14Q1IPu3g/T0GF78NjNPwCS6hWpset9ESWDm49U7XMLpN/dm4RGDPfDphxhVQaKDH+OnbvTXvz0aD21S4u6tZT8RVzxx/wKLn3Uim8R2/AfEnz/8h95GbIevwdJPqsRPo3uh/k4tH9Azx/+YPW+9ouwWEhw4u7GYMLyEzCQGVZqEeGyMz0+MkxH1S8pbZSa4gjjN3fruG4dEpARnwwfZN+83M7h/AFCDm2dd2vNFs+fwmlmJKpvU1a/ww8PjEgstjOIWLKhdtkmq1/EX+GCSnQyriSjFgobULRY4yLT7AjbkPBW8ifvPsQ3JGeUUNCyiTsHfJ+i5NoIjf04PRefZMetnV2aLeyksCWywZ029R2/0STRxjqG+LJz6IuveAxu8GY/8WmJZCRMKylewwYigvwbzkL4dDbZekP/DvsgN5XfRnx/q5XconFauPLLOXrDBjqVut/3ZHCl2BziBwL7vbfm01j14U86NUzAW9kv+mHn9hgut7FKzfpBvOI33MBUmM9s6WWR0whW/faPVrQMV3dQLo7j1LjLU7h5tH1/ix1ZV3qFffDsB7LDquDFrC4ZRBX8TUpNiJpD6sFdOfpsmLBBds5MQvm3nk7tc3B5i2swzoZtaYvekGqygGFZMC4n5oFJBTEXrgehujw86XsLYnSqWnjKgvbW/qdHaYuuOECd+6TD6pRg3w62ZmlAAk8LA740zpB0XVBjTOFvQhOL/JCxu2xCtn8GMfTDlRMbeyf6kd9StE+SW79RqvxwqgGcvLjXSFmNCxL1DHU1Rr1T/ALTKI2InMqtmDWgX+fvkDD/abjhMkpri7n8R9Q7ibDFG3F30F19qR0/JLXO+KlF Jv+cBNQa JhtWumksD1PlYLtPVPt4aYTE+EVZyD9zMWtH6DkOuIEGGzCxklaXkxtGgd9yWI1mz7OC9QpaN41bJ1VYtKMqjgQnIZ7z/y9x2TG+pa/7l5H9GvliiXsyvzX1Kzod0jVL8H9/N/AGrvud1ckhb74tYkrNTheOhJX2meQq7O98H1lR8oltqO40Vd1W4dsg8JFZ1UHRiqr7RgXUKbQFhnFfRBD9NzBgThzzsnIOBJfnbOKudLy9lQmwcvzGwXCJ0nKmIZP8oFd/5whZj1dPrFaEs3HR/xbE+DLgvNaynWN//i1eSFwwsPX/Jt/5FtI7UagQ1z5/+KWaLp7vjqMnu+1MJF6vAiep9+pmRipdRyPAQfsfng57yyyfFZsDc7WF7H8GcXG137cpoxLoAjo59512z50Rb/h1yblnLEDTbB+zuDtLPmmOwg09mce6CukM9goKNvAYaRhE1iX9P39ysNsYG2MvbbKioTH4lPSLF0NNgsLSELBk2LUA9SxUtyJ2Q/q9hzzrTg7ORRkOAVBEu7NcQ7R1W5EFFeNhCGn+Av9vgIKNN4GPiMTycrEFqjbGcyZ3IDrKunknhh0Vn4FN8H+JqyumxSD5RPzLKHBRS8aGYQXHFdUP09/twcLh5/EKW34LmMVVDuNG/M7VE1LzeU1U1f5j9m3vbmVbrZKC80nJSEIqtAyAUadeSQR5+cWjTm4FZ1N742uU1bHAUMW0= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000016, 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:08PM -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 unsigned wrap-around addition test to use > check_add_overflow(), retaining the result for later usage (which removes > the redundant open-coded addition). This paves the way to enabling the > unsigned wrap-around sanitizer[2] 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 | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index d12a17fc0c17..7932ac99e9d3 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -1223,6 +1223,7 @@ is_within_this_va(struct vmap_area *va, unsigned long size, > unsigned long align, unsigned long vstart) > { > unsigned long nva_start_addr; > + unsigned long sum; > > if (va->va_start > vstart) > nva_start_addr = ALIGN(va->va_start, align); > @@ -1230,11 +1231,11 @@ is_within_this_va(struct vmap_area *va, unsigned long size, > nva_start_addr = ALIGN(vstart, align); > > /* Can be overflowed due to big size or alignment. */ > - if (nva_start_addr + size < nva_start_addr || > + if (check_add_overflow(nva_start_addr, size, &sum) || > nva_start_addr < vstart) > return false; > > - return (nva_start_addr + size <= va->va_end); > + return (sum <= va->va_end); > } > > /* > -- > 2.34.1 > Looks good to me, Reviewed-by: Lorenzo Stoakes