From: Uladzislau Rezki <urezki@gmail.com>
To: Kees Cook <keescook@chromium.org>
Cc: Uladzislau Rezki <urezki@gmail.com>,
Lorenzo Stoakes <lstoakes@gmail.com>,
linux-hardening@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Christoph Hellwig <hch@infradead.org>,
linux-mm@kvack.org, "Gustavo A. R. Silva" <gustavoars@kernel.org>,
Bill Wendling <morbo@google.com>,
Justin Stitt <justinstitt@google.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 33/82] mm/vmalloc: Refactor intentional wrap-around calculation
Date: Wed, 31 Jan 2024 10:44:53 +0100 [thread overview]
Message-ID: <ZboWlVrD0TgeBo3J@pc636> (raw)
In-Reply-To: <202401301356.4F87B727@keescook>
On Tue, Jan 30, 2024 at 01:57:12PM -0800, Kees Cook wrote:
> On Tue, Jan 30, 2024 at 08:54:00PM +0100, Uladzislau Rezki wrote:
> > On Tue, Jan 30, 2024 at 06:55:57PM +0000, Lorenzo Stoakes wrote:
> > > 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 <akpm@linux-foundation.org>
> > > > Cc: Uladzislau Rezki <urezki@gmail.com>
> > > > Cc: Christoph Hellwig <hch@infradead.org>
> > > > Cc: Lorenzo Stoakes <lstoakes@gmail.com>
> > > > Cc: linux-mm@kvack.org
> > > > Signed-off-by: Kees Cook <keescook@chromium.org>
> > > > ---
> > > > 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 <lstoakes@gmail.com>
> > >
> > Same here. One small nit though. The "sum" variable is not something
> > that it suits for. IMO, we should use a better name and replace it:
> >
> > "nva_offset"?
>
> Sure, I can use that. Other folks in other patches have suggested "end",
> so maybe nva_end or nva_end_addr ?
>
nva_end_addr is probably the best fit.
--
Uladzislau Rezki
next prev parent reply other threads:[~2024-01-31 9:44 UTC|newest]
Thread overview: 163+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-23 0:26 [PATCH 00/82] overflow: Refactor open-coded arithmetic wrap-around Kees Cook
2024-01-23 0:26 ` [PATCH 01/82] overflow: Expand check_add_overflow() for pointer addition Kees Cook
2024-01-26 22:52 ` Justin Stitt
2024-01-26 22:57 ` Kees Cook
2024-01-23 0:26 ` [PATCH 02/82] overflow: Introduce add_would_overflow() Kees Cook
2024-01-23 8:03 ` Rasmus Villemoes
2024-01-23 21:38 ` Kees Cook
2024-01-23 0:26 ` [PATCH 03/82] overflow: Introduce add_wrap() Kees Cook
2024-01-23 8:14 ` Rasmus Villemoes
2024-01-23 21:51 ` Kees Cook
2024-01-23 9:22 ` Mark Rutland
2024-01-23 21:52 ` Kees Cook
2024-01-23 0:26 ` [PATCH 04/82] docs: deprecated.rst: deprecate open-coded arithmetic wrap-around Kees Cook
2024-01-23 0:26 ` [PATCH 05/82] cocci: Refactor " Kees Cook
2024-01-23 0:26 ` [PATCH 06/82] overflow: Reintroduce signed and unsigned overflow sanitizers Kees Cook
2024-01-23 2:24 ` Miguel Ojeda
2024-01-23 4:45 ` Kees Cook
2024-01-23 11:20 ` Miguel Ojeda
2024-01-23 0:26 ` [PATCH 07/82] overflow: Introduce CONFIG_UBSAN_POINTER_WRAP Kees Cook
2024-01-23 0:26 ` [PATCH 08/82] iov_iter: Avoid wrap-around instrumentation in copy_compat_iovec_from_user Kees Cook
2024-01-23 0:26 ` [PATCH 09/82] select: Avoid wrap-around instrumentation in do_sys_poll() Kees Cook
2024-01-23 18:00 ` Jan Kara
2024-01-23 0:26 ` [PATCH 10/82] locking/atomic/x86: Silence intentional wrapping addition Kees Cook
2024-01-23 9:27 ` Mark Rutland
2024-01-23 21:54 ` Kees Cook
2024-01-23 0:26 ` [PATCH 11/82] arm64: atomics: lse: " Kees Cook
2024-01-23 9:53 ` Mark Rutland
2024-01-23 0:26 ` [PATCH 12/82] ipv4: " Kees Cook
2024-01-23 0:26 ` [PATCH 13/82] btrfs: Refactor intentional wrap-around calculation Kees Cook
2024-01-23 1:45 ` David Sterba
2024-01-23 0:26 ` [PATCH 14/82] smb: client: " Kees Cook
2024-01-23 0:26 ` [PATCH 15/82] dma-buf: " Kees Cook
2024-01-23 0:26 ` [PATCH 16/82] drm/nouveau/mmu: " Kees Cook
2024-01-23 0:26 ` [PATCH 17/82] drm/vc4: " Kees Cook
2024-01-23 0:26 ` [PATCH 18/82] ext4: " Kees Cook
2024-01-23 0:26 ` [PATCH 19/82] fs: " Kees Cook
2024-01-23 18:01 ` Jan Kara
2024-01-23 0:26 ` [PATCH 20/82] fpga: dfl: " Kees Cook
2024-01-23 0:26 ` [PATCH 21/82] drivers/fsi: " Kees Cook
2024-01-23 0:26 ` [PATCH 22/82] x86/sgx: " Kees Cook
2024-01-23 9:15 ` Jarkko Sakkinen
2024-01-23 0:26 ` [PATCH 23/82] KVM: " Kees Cook
2024-01-24 16:25 ` Sean Christopherson
2024-01-23 0:26 ` [PATCH 24/82] KVM: arm64: vgic: " Kees Cook
2024-01-23 10:49 ` Marc Zyngier
2024-01-24 15:13 ` Eric Auger
2024-01-23 0:27 ` [PATCH 25/82] KVM: SVM: " Kees Cook
2024-01-24 16:15 ` Sean Christopherson
2024-01-23 0:27 ` [PATCH 26/82] buildid: " Kees Cook
2024-01-23 0:27 ` [PATCH 27/82] m68k: " Kees Cook
2024-01-23 2:29 ` Liam R. Howlett
2024-01-23 8:13 ` Geert Uytterhoeven
2024-01-23 13:29 ` Eero Tamminen
2024-01-23 13:42 ` Geert Uytterhoeven
2024-01-23 0:27 ` [PATCH 28/82] niu: " Kees Cook
2024-01-23 0:27 ` [PATCH 29/82] rds: " Kees Cook
2024-01-23 0:27 ` [PATCH 30/82] s390/kexec_file: " Kees Cook
2024-01-31 14:22 ` Alexander Gordeev
2024-01-31 14:40 ` Sven Schnelle
2024-01-23 0:27 ` [PATCH 31/82] ARC: dw2 unwind: " Kees Cook
2024-01-23 0:27 ` [PATCH 32/82] vringh: " Kees Cook
2024-01-26 19:31 ` Eugenio Perez Martin
2024-01-26 19:42 ` Kees Cook
2024-01-23 0:27 ` [PATCH 33/82] mm/vmalloc: " Kees Cook
2024-01-30 18:55 ` Lorenzo Stoakes
2024-01-30 19:54 ` Uladzislau Rezki
2024-01-30 21:57 ` Kees Cook
2024-01-31 9:44 ` Uladzislau Rezki [this message]
2024-01-23 0:27 ` [PATCH 34/82] ipc: " Kees Cook
2024-01-23 1:07 ` Linus Torvalds
2024-01-23 1:38 ` Kees Cook
2024-01-23 18:06 ` Linus Torvalds
2024-01-23 19:00 ` Kees Cook
2024-01-23 0:27 ` [PATCH 35/82] ACPI: custom_method: Refactor intentional wrap-around test Kees Cook
2024-01-24 19:52 ` Rafael J. Wysocki
2024-01-24 20:16 ` Kees Cook
2024-01-23 0:27 ` [PATCH 36/82] agp: " Kees Cook
2024-01-23 0:27 ` [PATCH 37/82] aio: " Kees Cook
2024-01-23 15:30 ` Christian Brauner
2024-01-23 18:03 ` Jan Kara
2024-01-23 0:27 ` [PATCH 38/82] arm: 3117/1: " Kees Cook
2024-01-23 9:56 ` Mark Rutland
2024-01-23 22:41 ` Kees Cook
2024-01-23 0:27 ` [PATCH 39/82] crypto: " Kees Cook
2024-01-23 0:27 ` [PATCH 40/82] arm64: stacktrace: " Kees Cook
2024-01-23 9:58 ` Mark Rutland
2024-01-23 0:27 ` [PATCH 41/82] wil6210: " Kees Cook
2024-01-23 6:36 ` Kalle Valo
2024-01-23 11:50 ` Kalle Valo
2024-01-23 22:52 ` Kees Cook
2024-01-23 0:27 ` [PATCH 42/82] bcachefs: " Kees Cook
2024-01-23 6:36 ` Kent Overstreet
2024-01-23 0:27 ` [PATCH 43/82] bpf: " Kees Cook
2024-01-23 4:00 ` Yonghong Song
2024-01-23 4:07 ` Kees Cook
2024-01-23 5:13 ` Yonghong Song
2024-01-23 0:27 ` [PATCH 44/82] btrfs: " Kees Cook
2024-01-23 18:00 ` David Sterba
2024-01-23 0:27 ` [PATCH 45/82] cifs: " Kees Cook
2024-01-23 0:27 ` [PATCH 46/82] crypto: " Kees Cook
2024-01-23 3:07 ` Eric Biggers
2024-01-23 3:29 ` Kees Cook
2024-01-23 0:27 ` [PATCH 47/82] dm verity: " Kees Cook
2024-01-30 18:58 ` Mike Snitzer
2024-01-23 0:27 ` [PATCH 48/82] drm/nouveau/mmu: " Kees Cook
2024-01-23 0:27 ` [PATCH 49/82] drm/i915: " Kees Cook
2024-01-23 0:27 ` [PATCH 50/82] drm/vc4: " Kees Cook
2024-01-23 0:27 ` [PATCH 51/82] ext4: " Kees Cook
2024-01-23 0:27 ` [PATCH 52/82] f2fs: " Kees Cook
2024-01-23 0:27 ` [PATCH 53/82] fs: " Kees Cook
2024-01-23 18:02 ` Jan Kara
2024-01-23 0:27 ` [PATCH 54/82] hpfs: " Kees Cook
2024-01-23 0:27 ` [PATCH 55/82] kasan: " Kees Cook
2024-01-25 22:35 ` Andrey Konovalov
2024-01-23 0:27 ` [PATCH 56/82] usercopy: " Kees Cook
2024-01-23 0:27 ` [PATCH 57/82] KVM: arm64: vgic-v3: " Kees Cook
2024-01-23 10:50 ` Marc Zyngier
2024-01-24 15:12 ` Eric Auger
2024-01-23 0:27 ` [PATCH 58/82] s390/mm: " Kees Cook
2024-01-23 0:27 ` [PATCH 59/82] lib/scatterlist: " Kees Cook
2024-01-23 0:27 ` [PATCH 60/82] powerpc: " Kees Cook
2024-02-12 5:38 ` Michael Ellerman
2024-01-23 0:27 ` [PATCH 61/82] scsi: mpt3sas: " Kees Cook
2024-01-23 0:27 ` [PATCH 62/82] mwifiex: pcie: " Kees Cook
2024-01-23 6:36 ` Kalle Valo
2024-01-23 0:27 ` [PATCH 63/82] mm: " Kees Cook
2024-01-23 0:27 ` [PATCH 64/82] netfilter: " Kees Cook
2024-01-23 18:03 ` Florian Westphal
2024-01-23 0:27 ` [PATCH 65/82] nios2: " Kees Cook
2024-01-23 13:15 ` Dinh Nguyen
2024-01-23 0:27 ` [PATCH 66/82] fs/ntfs3: " Kees Cook
2024-01-23 0:27 ` [PATCH 67/82] ocfs2: " Kees Cook
2024-01-23 0:27 ` [PATCH 68/82] PCI: " Kees Cook
2024-01-23 0:27 ` [PATCH 69/82] perf tools: " Kees Cook
2024-01-23 6:21 ` Adrian Hunter
2024-01-23 21:31 ` Kees Cook
2024-01-23 0:27 ` [PATCH 70/82] remoteproc: " Kees Cook
2024-02-06 18:55 ` Bjorn Andersson
2024-01-23 0:27 ` [PATCH 71/82] s390/mm: " Kees Cook
2024-01-23 0:27 ` [PATCH 72/82] scsi: sd_zbc: " Kees Cook
2024-01-23 0:27 ` [PATCH 73/82] sh: " Kees Cook
2024-01-23 7:31 ` John Paul Adrian Glaubitz
2024-01-23 0:27 ` [PATCH 74/82] ARC: dw2 unwind: " Kees Cook
2024-01-23 0:27 ` [PATCH 75/82] timekeeping: " Kees Cook
2024-01-23 1:06 ` John Stultz
2024-01-24 19:34 ` Thomas Gleixner
2024-01-23 0:27 ` [PATCH 76/82] udf: " Kees Cook
2024-01-23 17:14 ` Jan Kara
2024-01-23 0:27 ` [PATCH 77/82] virtio: " Kees Cook
2024-01-26 19:33 ` Eugenio Perez Martin
2024-01-23 0:27 ` [PATCH 78/82] mm/vmalloc: " Kees Cook
2024-01-30 18:56 ` Lorenzo Stoakes
2024-01-23 0:27 ` [PATCH 79/82] staging: vme_user: " Kees Cook
2024-01-23 0:27 ` [PATCH 80/82] xen-netback: " Kees Cook
2024-01-23 7:55 ` Jan Beulich
2024-01-23 21:32 ` Kees Cook
2024-01-23 0:27 ` [PATCH 81/82] lib: zstd: " Kees Cook
2024-01-23 0:27 ` [PATCH 82/82] mqueue: " Kees Cook
2024-01-23 2:22 ` [PATCH 00/82] overflow: Refactor open-coded arithmetic wrap-around Kent Overstreet
2024-01-23 2:51 ` Kees Cook
2024-01-23 9:46 ` Mark Rutland
2024-01-23 21:56 ` Kees Cook
2024-01-29 6:27 ` Kees Cook
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZboWlVrD0TgeBo3J@pc636 \
--to=urezki@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=gustavoars@kernel.org \
--cc=hch@infradead.org \
--cc=justinstitt@google.com \
--cc=keescook@chromium.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lstoakes@gmail.com \
--cc=morbo@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).