From patchwork Tue Jan 23 00:26:44 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kees Cook X-Patchwork-Id: 13526624 Received: from mail-pf1-f182.google.com (mail-pf1-f182.google.com [209.85.210.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 482D2157043 for ; Tue, 23 Jan 2024 00:28:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.182 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705969732; cv=none; b=nsUXSmMDRya0mVkc+ZU+Zpx+v1L6VtOrkLxeeRAdQ6xaViyebAvQRvbcE2TLV6AzVuOwqSB18F6v0y3yahXsYRKEdQJvcNWA+Qg9VY39yOYOLX+cGM2DeEWpkm3aAcwSJ87IhM5lLhYV5ePGvgRHjEg+1iq3sZIEnh8U3AXaekA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705969732; c=relaxed/simple; bh=PmD97Weq3WllHYy9c/D1C/9IrSV8qUdF4whlDGfFZE8=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=i56M027RTbAh/Y753Mpcu7GXHfEqx86Rji0OTNwjDNpVwwgsXMiKziZS0M9PrW0nwdqWmJt63BDg+osvcCjx+hJiAsmXg4n+C1c3J3VAxkV6Us/uT3IuKL6Uz0tcrcW4YrCjD4CPstu/+homxUvjKm0NAb/Fj0rWG63XiWeO0UQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org; spf=pass smtp.mailfrom=chromium.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b=KxLuwfNe; arc=none smtp.client-ip=209.85.210.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="KxLuwfNe" Received: by mail-pf1-f182.google.com with SMTP id d2e1a72fcca58-6d9b37f4804so2839238b3a.1 for ; Mon, 22 Jan 2024 16:28:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1705969729; x=1706574529; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=3TGYFkY09Xk6GAlz0uNRUAdH36K12Z/wH1iFNj2bT+k=; b=KxLuwfNeRJ+hmFoGPgKZdlSk+AYoOwcnwNz/P+4GZsPoSKEZ9HNAHLvM+HANHQRZT4 IkXcv9H6RXrMOIwSYUYQinVC0WWTcub5AISix0D2fUXvIdSWUUfQmcTkEZYPNnWvb/0j MbKKp5qCJvCY3jSKGtEiavNakTz/xerufCI8Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705969729; x=1706574529; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=3TGYFkY09Xk6GAlz0uNRUAdH36K12Z/wH1iFNj2bT+k=; b=OrjYEcA22NfHoKGik13N5D+ASCzp30fOb7n1cZZp0pUwK8TUyaZPRUEnDKM0i+4Ug9 pjutNyrgq+AACYo8HrusfLcYfXf0PzX2AuZzjvhKeLU5qRs1ZQJNlqgshx1FfvWpXLxZ LLf3kyprDDU30dWj6iO8zsRXJb9Fa/luhfXRz5AgwL4xDq64D6KbEuXTbXUw8FYyDFkz 8/LD69sHDebliLqeF+uj2S4PFnc0BYq8bNE0Wijab+ef9fOKvoXZof3g16I+sUZlPMLW YF17o+NQsaz8F3NNH/UIwfU3kd7iwKIHFYe4je8kSgj+EFVpoGx/H/3WjchKvtNrOgVk QEBw== X-Gm-Message-State: AOJu0Yw531W7ffVnXI1PmNWrXfLkdCqfXUIkFTvjvXej4KKTtaYnuCcA /s6QaTWHlq60AwlPmwJ28fmsLIhAVXyCaS/3Aes87dl8cOhZ7c04Pz6Qvfxg0w== X-Google-Smtp-Source: AGHT+IEfA0xPtU78X5p9h/WA+ZnUOTlNVoIOWKUAiv95UE+kyy39ruCd+kJ3jzTf5eQRZGjVvYX/ow== X-Received: by 2002:a05:6a21:a59a:b0:19b:5b08:1f4b with SMTP id gd26-20020a056a21a59a00b0019b5b081f4bmr5434332pzc.15.1705969729702; Mon, 22 Jan 2024 16:28:49 -0800 (PST) Received: from www.outflux.net ([198.0.35.241]) by smtp.gmail.com with ESMTPSA id j3-20020a056a00130300b006d9c216a9e6sm10138528pfu.56.2024.01.22.16.28.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Jan 2024 16:28:37 -0800 (PST) From: Kees Cook To: linux-hardening@vger.kernel.org Cc: Kees Cook , Alexander Viro , Christian Brauner , Jan Kara , linux-fsdevel@vger.kernel.org, "Gustavo A. R. Silva" , Bill Wendling , Justin Stitt , linux-kernel@vger.kernel.org Subject: [PATCH 09/82] select: Avoid wrap-around instrumentation in do_sys_poll() Date: Mon, 22 Jan 2024 16:26:44 -0800 Message-Id: <20240123002814.1396804-9-keescook@chromium.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240122235208.work.748-kees@kernel.org> References: <20240122235208.work.748-kees@kernel.org> Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=2641; i=keescook@chromium.org; h=from:subject; bh=PmD97Weq3WllHYy9c/D1C/9IrSV8qUdF4whlDGfFZE8=; b=owEBbQKS/ZANAwAKAYly9N/cbcAmAcsmYgBlrwgEytnksz1bThGRY5DK5TacZnS6Yl60KDnSM 2MX5BKOiv6JAjMEAAEKAB0WIQSlw/aPIp3WD3I+bhOJcvTf3G3AJgUCZa8IBAAKCRCJcvTf3G3A Jsc5D/4y3WYeKpzWOOCxgpOBEmELwR2i5cXRFClXQT8Dh5kznbNc+qjzrcINPA5tfSMCKqksOx2 waq122UgLgvDs7kGRlptl6E9Kprq6DsDw7wdLfNoA3H+ez8jQf7JMzOFjWisqc+q+jJGBKio24e t5vJf6GnubB4mzBH4cZa61OqBJLmA1GNOx2gzWHE7j2iHZt5Iy2clBMGTO3SJukqU+UEfX1LM96 E6oSsKlWVm1gG+iB/RYC5pJmH5aFoHPKxdNYXiMUR6/fPhx42TmcBw7unDDy1oG+rxPjMPPMZT2 leZok2gnYc4BwgPfLMNk9ETxLWf+k36o/uDLrgpw/LraN9jvCqUzOUFCpFPD5+N4O0XII2AdJ+A tJK7FysfIpkuh80CwTkFnjC8SIOpbkM+mSyJ7PdArgrVe0L63H/dBv6ZlwKDZ5C/XX09BrbP3QC q2Yy0UBMTqv1wOFi9U04tsQ5mQ07h1ZuvDzmUtltQobblFJDqZq8WS6mT/pfB26btDsAJ2hBv6v YQEZZaUcq9UKzCcx9V1ZRnULm3/5JmndEptvjMNPeJk7dKuVUADDoSQYcb0YgpFZrwk1LSVwvLY wjTpDJn01qEVtVti3Y1lPIiR2B4JRJTy/PVM5W6p1kAdrkPJjFXMwq+zftEur4gCaiNYE5uahWZ R3xr3G8bEQBxjAw== X-Developer-Key: i=keescook@chromium.org; a=openpgp; fpr=A5C3F68F229DD60F723E6E138972F4DFDC6DC026 The mix of int, unsigned int, and unsigned long used by struct poll_list::len, todo, len, and j meant that the signed overflow sanitizer got worried it needed to instrument several places where arithmetic happens between these variables. Since all of the variables are always positive and bounded by unsigned int, use a single type in all places. Additionally expand the zero-test into an explicit range check before updating "todo". This keeps sanitizer instrumentation[1] out of a UACCESS path: vmlinux.o: warning: objtool: do_sys_poll+0x285: call to __ubsan_handle_sub_overflow() with UACCESS enabled Cc: Alexander Viro Cc: Christian Brauner Cc: Jan Kara Cc: linux-fsdevel@vger.kernel.org Signed-off-by: Kees Cook Reviewed-by: Jan Kara --- fs/select.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/fs/select.c b/fs/select.c index 0ee55af1a55c..11a3b1312abe 100644 --- a/fs/select.c +++ b/fs/select.c @@ -839,7 +839,7 @@ SYSCALL_DEFINE1(old_select, struct sel_arg_struct __user *, arg) struct poll_list { struct poll_list *next; - int len; + unsigned int len; struct pollfd entries[]; }; @@ -975,14 +975,15 @@ static int do_sys_poll(struct pollfd __user *ufds, unsigned int nfds, struct timespec64 *end_time) { struct poll_wqueues table; - int err = -EFAULT, fdcount, len; + int err = -EFAULT, fdcount; /* Allocate small arguments on the stack to save memory and be faster - use long to make sure the buffer is aligned properly on 64 bit archs to avoid unaligned access */ long stack_pps[POLL_STACK_ALLOC/sizeof(long)]; struct poll_list *const head = (struct poll_list *)stack_pps; struct poll_list *walk = head; - unsigned long todo = nfds; + unsigned int todo = nfds; + unsigned int len; if (nfds > rlimit(RLIMIT_NOFILE)) return -EINVAL; @@ -998,9 +999,9 @@ static int do_sys_poll(struct pollfd __user *ufds, unsigned int nfds, sizeof(struct pollfd) * walk->len)) goto out_fds; - todo -= walk->len; - if (!todo) + if (walk->len >= todo) break; + todo -= walk->len; len = min(todo, POLLFD_PER_PAGE); walk = walk->next = kmalloc(struct_size(walk, entries, len), @@ -1020,7 +1021,7 @@ static int do_sys_poll(struct pollfd __user *ufds, unsigned int nfds, for (walk = head; walk; walk = walk->next) { struct pollfd *fds = walk->entries; - int j; + unsigned int j; for (j = walk->len; j; fds++, ufds++, j--) unsafe_put_user(fds->revents, &ufds->revents, Efault); From patchwork Tue Jan 23 00:26:54 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kees Cook X-Patchwork-Id: 13526625 Received: from mail-oo1-f41.google.com (mail-oo1-f41.google.com [209.85.161.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AEB6755E5E for ; Tue, 23 Jan 2024 00:28:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.161.41 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705969738; cv=none; b=lFIcDAe0ahOan+BIx52BOCqsNo2+cBnovJR18RJnEVBaUqEInsEpwh0+1qVLkye9dIMJhyxoJHQDLS9o6zs9KFyHQnk2szbFvi0dsQAt69PRFKrQL3Nr8H/xoo2Fm15bRYJIbU6FjD2+0mPo5SMA1rWHrQ3ua4Z3BX5n4Et4MYg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705969738; c=relaxed/simple; bh=hmcJNNt4Q4VRdZF2vWAi73bsrPppPr3nSkhgxxWjJIU=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=cLC4vyodZZqawuhI79USLLvLgDfrC8miKoEzkD4saj5z551lGJ1igFY72NDDCm4+M0hrEPueJM7XpFVhxOx7OinUEZRDwI69BAaVbtoRcb66BGnKQGxAzYuv8BnMtlLTptKc9zYn7d4IgYvWxEKHZ7Td4nljsnop6M3vD8Ck42k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org; spf=pass smtp.mailfrom=chromium.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b=khxnD3rI; arc=none smtp.client-ip=209.85.161.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="khxnD3rI" Received: by mail-oo1-f41.google.com with SMTP id 006d021491bc7-59969ec581aso1446917eaf.0 for ; Mon, 22 Jan 2024 16:28:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1705969736; x=1706574536; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=Lj0wfLNXUIfcFcpxjFCj6rC1hxMeO39B1XcxU2Z6FQQ=; b=khxnD3rIeNf8wx6F/TQfF4EEXCdrUsJ4+NeWzVmT1mI1f+lo+i4Dk7LgSq+osT3SEA KxgxZpCW92L3GUsZh5Jyaz2aWeyeJRR/3iIi/HwlPFThTDlD1mrZopKzTtjEKgD7QVAh g71KNRZ9m20hb9ja0eqTu2qjZUyFjs032ZAKY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705969736; x=1706574536; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Lj0wfLNXUIfcFcpxjFCj6rC1hxMeO39B1XcxU2Z6FQQ=; b=YV1rXk9zKqkvTOFtJ+wWCHbvs61ckMLw6e52E8U+gvBmxHxirQZX08Jdz9k4nCMXYn Tr7aFe2AAEnxRZ8mR7Ax2kGmUFS9fxWYzbgh5t4odJM44lx4z56xVYopo4dUEpsnHF0A /4pfh/ejwxWf32lZV6tstn70W/03VEJ5U0vtaf/TI6T383hVuSzHKKUEp3IR2WTu2Rk+ U5KvCO7PE8AbrpB8gvarzUb2bTrMlz/VxnekGK6gVdGDtUl2lRcPFZlc5PW6FmItQl1F UB/xHyPrvSQ6e6FhkiJuLnnp4nIcv2z3AAb214NeQgbp7GphqY7Hdx9mN84Nhuo2sQdn 18Qg== X-Gm-Message-State: AOJu0YydYhsRJzrndFSBbpttAdZ6JQlzWNamw+K9brKh7c8YO0xtvRWI 08D09O8tLCoPMNmy1ItX+OPpcnUUfiTQ/T04Srl9QpML1bB9/xydB3dIVN6VJA== X-Google-Smtp-Source: AGHT+IGxMyxotbMc1Cchrsm3rFcXhbTFlmI7s6erqf4s8ue04bzsUyGWqJUWv1AxYbLOpHQJNEDrtg== X-Received: by 2002:a05:6358:9044:b0:171:4aa4:51 with SMTP id f4-20020a056358904400b001714aa40051mr2816637rwf.54.1705969735934; Mon, 22 Jan 2024 16:28:55 -0800 (PST) Received: from www.outflux.net ([198.0.35.241]) by smtp.gmail.com with ESMTPSA id sv13-20020a17090b538d00b0028d8fa0171asm10226018pjb.35.2024.01.22.16.28.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Jan 2024 16:28:49 -0800 (PST) From: Kees Cook To: linux-hardening@vger.kernel.org Cc: Kees Cook , Alexander Viro , Christian Brauner , Jan Kara , linux-fsdevel@vger.kernel.org, "Gustavo A. R. Silva" , Bill Wendling , Justin Stitt , linux-kernel@vger.kernel.org Subject: [PATCH 19/82] fs: Refactor intentional wrap-around calculation Date: Mon, 22 Jan 2024 16:26:54 -0800 Message-Id: <20240123002814.1396804-19-keescook@chromium.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240122235208.work.748-kees@kernel.org> References: <20240122235208.work.748-kees@kernel.org> Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=2642; i=keescook@chromium.org; h=from:subject; bh=hmcJNNt4Q4VRdZF2vWAi73bsrPppPr3nSkhgxxWjJIU=; b=owEBbQKS/ZANAwAKAYly9N/cbcAmAcsmYgBlrwgFKlHII6LhFKix+ewETmVbpfBbbfsybJbPD x+7qNyR682JAjMEAAEKAB0WIQSlw/aPIp3WD3I+bhOJcvTf3G3AJgUCZa8IBQAKCRCJcvTf3G3A JliJD/sHf6ZqD8B/KWziPKmgyfqtW/R2omfg5NRF8ncdgxikerGRRFZGCvxzR4FW8MnjOxVf1uq VTlOujj9IdXmUGBNs6tlOuMkwDYDNxnpu2AhJz2L1ONpzLxW1Wo9TMy8M28suhDxJcE4bIhyVGL Fx2SEqEqstNDAG3Rd3j69TdEahfsyFepNOoEczntilqiJVXn+EVQfiYKnLqJOs/ClIXcT4I3UA0 K5aspcqb7nZa9d9oLHl/gnMr+7tzhUthPyt2nmE9yXR1trn1C7UxLbzym+BovDdAEmBNHATqitV gowcGG8q+UqAhrey3vsLtf5HImIOfkVd+TOcmaqoeKn0pdU+2ClklkZWWuSPZ487SM0cmDnz2C1 iGtEgxQSBrtf6GBC2d/etauF2TPzcSWLiA50TwSZMMnEv0e4ZAjBomBLGt6/oodBN4EEKFko0IC z7lNnU1chyMq5++BG9oppW4tU35qUGbM70e7vW5R2VenZeVNle7WRMV9PM7aoCll9FDyToggtFh y3nM1tyfxmnPcmhkmr6Arv/MeRImecDofJlbA8Gq1/NTHBdFh5h7VJz33oSPSRmR4KNJajQwru0 oV6bvQm+LM2rktW39ya9RNbnqonExofCyI0arK6BQ3PYO4mcSczuAwRcMy9ABCKxBGIs9zpXCoo aXWaEhK33clY8pQ== X-Developer-Key: i=keescook@chromium.org; a=openpgp; fpr=A5C3F68F229DD60F723E6E138972F4DFDC6DC026 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 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: Alexander Viro Cc: Christian Brauner Cc: Jan Kara Cc: linux-fsdevel@vger.kernel.org Signed-off-by: Kees Cook Reviewed-by: Jan Kara --- fs/read_write.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/fs/read_write.c b/fs/read_write.c index d4c036e82b6c..e24b94a8937d 100644 --- a/fs/read_write.c +++ b/fs/read_write.c @@ -1417,6 +1417,7 @@ static int generic_copy_file_checks(struct file *file_in, loff_t pos_in, struct inode *inode_out = file_inode(file_out); uint64_t count = *req_count; loff_t size_in; + loff_t sum_in, sum_out; int ret; ret = generic_file_rw_checks(file_in, file_out); @@ -1451,7 +1452,8 @@ static int generic_copy_file_checks(struct file *file_in, loff_t pos_in, return -ETXTBSY; /* Ensure offsets don't wrap. */ - if (pos_in + count < pos_in || pos_out + count < pos_out) + if (check_add_overflow(pos_in, count, &sum_in) || + check_add_overflow(pos_out, count, &sum_out)) return -EOVERFLOW; /* Shorten the copy to EOF */ @@ -1467,8 +1469,8 @@ static int generic_copy_file_checks(struct file *file_in, loff_t pos_in, /* Don't allow overlapped copying within the same file. */ if (inode_in == inode_out && - pos_out + count > pos_in && - pos_out < pos_in + count) + sum_out > pos_in && + pos_out < sum_in) return -EINVAL; *req_count = count; From patchwork Tue Jan 23 00:27:12 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kees Cook X-Patchwork-Id: 13526752 Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 332A2130E56 for ; Tue, 23 Jan 2024 01:03:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.170 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705971823; cv=none; b=CAbH2Qa7bCfDUIyBLmEjru59arVHtY08mRUALYdTQfcuOHNciqBmemH5LLRAzl79zTfYfj0QM3QP9KazkM+B86HvObrJh3Rm8l7uu6edQLugol13i/E+KsqD98T51PyUaLJGKFqZKOy/XbcqyA1UEC7R0+LPLYSSdhFsPX7Y/Vg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705971823; c=relaxed/simple; bh=IB2lfGkRCBtaWjh4efF33fJJqpbLbcQ8iv2Ec/oLFcg=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=rOAurGlzrMV4YJ59EMD22FwBnz4J+ScemwmHy+8vaOX75Vi6wXM8cP2JDLCU9exO4+//LkAsq3MsUaboTECKzz3HE3oYZZdN+VSyFGux1FkRyiw8XVcj5keD2YuUo+7tP3oNwD2upMKN48DDQ5n1ETXkex6klP320BEezuolMVM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org; spf=pass smtp.mailfrom=chromium.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b=l9fXPBfn; arc=none smtp.client-ip=209.85.214.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="l9fXPBfn" Received: by mail-pl1-f170.google.com with SMTP id d9443c01a7336-1d70a986c4aso14739245ad.2 for ; Mon, 22 Jan 2024 17:03:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1705971821; x=1706576621; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=X0d2UaZGLqhx8u565YivlSqF+Wqiy035MOx60/jiYzQ=; b=l9fXPBfnUqu56eaKYrQLJp2b6t5jO7o4VFSr0IhM5u54VaAqvyOLNQlJdySAnchxbj j/hTsyTkxD/fg3o/ioOnBmokyHL8aLKhHD/njv3BOI4otixka1sAKq2t0N17sU+NShKI 1JYFkxEoplYM3YpzRRldxq+tabf6v4KNCiB8o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705971821; x=1706576621; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=X0d2UaZGLqhx8u565YivlSqF+Wqiy035MOx60/jiYzQ=; b=qtrHcsHnmXXYsyNYwHDiLo++97mHbuw5ANo2EOilL3yW/2sIkaOY53C2aXpJYU+nuf VkVViSOCZszjwj42K9OwaHfw2WyDvCC3337OC446RcdbtiJME34JmOTyLmG6OkuDJ+by +dbaQ2tDHPtkI8jRZxr7KdCO5cdKYi0+XQ0mBc6SeHGb0kfQod4jynvj8kEXThDkjAFj J/Or7dKbFc6F2L7fj2NBqYmFeL2lKOMnlXH03DtpF2Cg9jV89fuyCxytQs604DMOo2y6 8ucdeA+2DH/LltV330u00BpVWmaJM7Nu/jS5+neL1MwAAUmNKPasIdX9HOOPejmp1wCs MXyw== X-Gm-Message-State: AOJu0Yysoedi5ibDYsypK7wXMje7ojOmeLHmgtrfRbiZxJlI6rDLq30A nhUrvVTsNjQsYWv3S2fpoe1QaEQsuhnE+BhbsC7NQgqq/xtX4iCADhw5FRAVxg== X-Google-Smtp-Source: AGHT+IHYE/R5XonXRWLS/O4LizE4LdUTB1VLzM4BkeSVTle2CM1WdJXziTFcWq98gVQnc9ulPPYiUg== X-Received: by 2002:a17:902:c952:b0:1d7:5ff8:ca07 with SMTP id i18-20020a170902c95200b001d75ff8ca07mr1511463pla.0.1705971821597; Mon, 22 Jan 2024 17:03:41 -0800 (PST) Received: from www.outflux.net ([198.0.35.241]) by smtp.gmail.com with ESMTPSA id s2-20020a17090302c200b001d707987ce3sm7538451plk.194.2024.01.22.17.03.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Jan 2024 17:03:38 -0800 (PST) From: Kees Cook To: linux-hardening@vger.kernel.org Cc: Kees Cook , Benjamin LaHaise , Alexander Viro , Christian Brauner , Jan Kara , linux-aio@kvack.org, linux-fsdevel@vger.kernel.org, "Gustavo A. R. Silva" , Bill Wendling , Justin Stitt , linux-kernel@vger.kernel.org Subject: [PATCH 37/82] aio: Refactor intentional wrap-around test Date: Mon, 22 Jan 2024 16:27:12 -0800 Message-Id: <20240123002814.1396804-37-keescook@chromium.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240122235208.work.748-kees@kernel.org> References: <20240122235208.work.748-kees@kernel.org> Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=1888; i=keescook@chromium.org; h=from:subject; bh=IB2lfGkRCBtaWjh4efF33fJJqpbLbcQ8iv2Ec/oLFcg=; b=owEBbQKS/ZANAwAKAYly9N/cbcAmAcsmYgBlrwgH+XJvl/2u5/B92EhxeYdENMTRs1wnkh1xr 9hUH/VuXyeJAjMEAAEKAB0WIQSlw/aPIp3WD3I+bhOJcvTf3G3AJgUCZa8IBwAKCRCJcvTf3G3A Jtg8D/9Kz/EW1ykUt81CF9pL76dSizLWvhro5VLsT0USPihaAkiPFGlwrR5ADLawemjbfsHCbL0 y2ajirjz/gpH+F9soxesI7UTKaOtXNfrDeLFYYBxCuKefSRjlhkjBdN240HgsAMOJQrh+pe04NH rTO/yRaleiNL0aZYSoZIvvEuMd1fzbVOXjXOgUh0vu+Hsv16H/4kN3dIXYmPovEduhXyTJgSGH7 ZGIslfnnmesh92mCEWrYn3rhjzLPCv7bWGujt9QQB96dWFdoz0ZN/EfR4AFYJhm/imLkEdIXduQ MUxFoV0gzuwMa87PuOG2dpH+U9DcliEY4H3Mq5RBdZs6wlbGVibNjbvVFxT4IoxpoLZLqlqQjch ZtxRmzdY8tMH/ZVW/mgikzYQifvrHq68kXRbwuglv+ZT81x8yxOlYRrQkY7XksLYSZAGda4eq73 L/JYedm444TLva1eDV9R9UubQ2witsDaqTjZE/59j4zQeKdcoRakQBVcJlqhLmv44lrrPDC66Iy hv89rogp1k5rLt4h3Ud8wIFgTl2Lz/z9UcUpYgMp9QRJgeWoBzQi1ZAOByDnDHwWLA7hx85V//T 3h+sL/yM7HR9K0A8NbZnruLp3tTkSoBzDEfB/XuJZvBkjRz6hG2z4ymvzYJ99psA2daJt9WCF+a APviVXHgDVSXNAg== X-Developer-Key: i=keescook@chromium.org; a=openpgp; fpr=A5C3F68F229DD60F723E6E138972F4DFDC6DC026 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: Benjamin LaHaise Cc: Alexander Viro Cc: Christian Brauner Cc: Jan Kara Cc: linux-aio@kvack.org Cc: linux-fsdevel@vger.kernel.org Signed-off-by: Kees Cook Reviewed-by: Jan Kara --- fs/aio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/aio.c b/fs/aio.c index bb2ff48991f3..edd19be3f4b1 100644 --- a/fs/aio.c +++ b/fs/aio.c @@ -796,7 +796,7 @@ static struct kioctx *ioctx_alloc(unsigned nr_events) /* limit the number of system wide aios */ spin_lock(&aio_nr_lock); if (aio_nr + ctx->max_reqs > aio_max_nr || - aio_nr + ctx->max_reqs < aio_nr) { + add_would_overflow(aio_nr, ctx->max_reqs)) { spin_unlock(&aio_nr_lock); err = -EAGAIN; goto err_ctx; From patchwork Tue Jan 23 00:27:28 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kees Cook X-Patchwork-Id: 13526626 Received: from mail-oi1-f179.google.com (mail-oi1-f179.google.com [209.85.167.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BE2D615AAA0 for ; Tue, 23 Jan 2024 00:29:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.179 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705969749; cv=none; b=KMEi+sG+c2HdzHoBz4DJaUAOsR/8K87LZqOlDiBfdJhHdeA2Lb7qas+YqS/vfZw8uuRbxFds/wrQTjwjsaqm+O1vXegn4Q9k2I8f7PTlp2vKHmfyu/D2TySDCdeli67EFBA9q3Im02EtJs4uclwWRhMy08Qr1GEN+I4rIHp3J94= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705969749; c=relaxed/simple; bh=nfo7Pn+Yi1zHl6gAcNSHg7VhEroNaouSkiXnEe5ME0I=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=IP8Rpu7z6hsUndpzPpT7SfrAlRXxosmVl3dpi2IFOxYUUQ2xrcZu3/Fk3+XE2Mij4FBEn8Wg7vQZjNwij991vHPocygVNX2R3v1gCR0CLY1XfeU+K0IdbhrsTI52+fhQJwdHpzC/Tb8+XqgDmi25nWULfttXMrmfAISsEbA3ZCE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org; spf=pass smtp.mailfrom=chromium.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b=fwYvh+of; arc=none smtp.client-ip=209.85.167.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="fwYvh+of" Received: by mail-oi1-f179.google.com with SMTP id 5614622812f47-3bd562d17dcso3107341b6e.3 for ; Mon, 22 Jan 2024 16:29:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1705969747; x=1706574547; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=bqOzYThsddRc/TP1ywPfEse4mdjcUMW6abmNPQSgVtA=; b=fwYvh+ofGDhJHVAXDPoztSdcYdb/g5pTbPhWug/P5ohZEGmUPv6kMUjzqQUbm3e5GC 6e+yxFc2cXyo/JVStGJUQ5UjOJZfMjc7kFV/1aW/WPSSAvbgu5iOoSw1llPsvHe9AaGf s/3rl6A6JqT13f1NSBu4SQ3qt21dGP/xinBtE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705969747; x=1706574547; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=bqOzYThsddRc/TP1ywPfEse4mdjcUMW6abmNPQSgVtA=; b=HypZwrzuyFDaBGOp2IZNDnfa3VlJt7HaHASkru4o+P9/K91nfT1TnmEUPjZPy97hdm u5cJmxBSgO2r/NzKyWORfNfor4mroFeKf/PX847LqhL+5QmAwocIFsfvB2mMLgdsrBV+ b2GJ5sdpFdmx7FqzUDDiCLXReYzSvAQ+Cd6/8c3xNBxWikK4w6Mo9j00fTlQhaQP0NSf gRIJ/4IS0oOcG4LEqWx4jqs2Q4vzAroRu6adrkwrWppxfW5QP8KdnDonehQ8haiOcGJO hyuwfdDo5EjvwigusNejeLphVQ+3BBYG3dohPATSg9piC4A9xdqbTp5zTucM+mbd4Mvu eTFA== X-Gm-Message-State: AOJu0YysZy4iHXdzh8Ua1S0d4pHRNbSYradXBEC/wGf2HYAp+mVwTxBA kI/ORgjwwWB1b7Z7F9R47/b/R9NftOFZ8xfC7n5+vtualiqHtXVc/8s7IMW6umcSRvVDWM20Pzc = X-Google-Smtp-Source: AGHT+IGWOLXCTwPI6j3GBh9rWczj1tm/GwWsrgoWZKK4I8jNyHd+KA4KE2ZFP1l8jjKQE1E/jOjvfA== X-Received: by 2002:a05:6808:1916:b0:3bd:8201:f5de with SMTP id bf22-20020a056808191600b003bd8201f5demr5861585oib.33.1705969746846; Mon, 22 Jan 2024 16:29:06 -0800 (PST) Received: from www.outflux.net ([198.0.35.241]) by smtp.gmail.com with ESMTPSA id y18-20020aa79e12000000b006d9ac45206bsm10198867pfq.206.2024.01.22.16.28.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Jan 2024 16:29:00 -0800 (PST) From: Kees Cook To: linux-hardening@vger.kernel.org Cc: Kees Cook , Alexander Viro , Christian Brauner , Jan Kara , linux-fsdevel@vger.kernel.org, "Gustavo A. R. Silva" , Bill Wendling , Justin Stitt , linux-kernel@vger.kernel.org Subject: [PATCH 53/82] fs: Refactor intentional wrap-around test Date: Mon, 22 Jan 2024 16:27:28 -0800 Message-Id: <20240123002814.1396804-53-keescook@chromium.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240122235208.work.748-kees@kernel.org> References: <20240122235208.work.748-kees@kernel.org> Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=1854; i=keescook@chromium.org; h=from:subject; bh=nfo7Pn+Yi1zHl6gAcNSHg7VhEroNaouSkiXnEe5ME0I=; b=owEBbQKS/ZANAwAKAYly9N/cbcAmAcsmYgBlrwgJNnJ/s6Wgv/6AhsrzLX4ud+nwKsZVT6phE 9TF2kTHZzqJAjMEAAEKAB0WIQSlw/aPIp3WD3I+bhOJcvTf3G3AJgUCZa8ICQAKCRCJcvTf3G3A JqgLD/9/8tepsjDo0cRyL40X6tIYA+MlThX9khW3Oe3bkhpOGQukol41PQ55NX8DKADGKtJeVXE zid5B46i5QDXe4vObMddWL03qTDHEu+NBMnj6IS1gcFy+ACV8M9LiMAjU+pEhRxIO7/NpMLI68u +AvCayzHQGjHq1qTfG2nYMi4TLZ9cRFbeZIun8kIm1YGDXWBctkqy3INiE/sR5MPcNpkAmIFxNz 1dKrxf1i211L4BkQyoO/InMUKRrYVDF78PVzluyJTqSgLEc9D5qCcI+Vo0VaBO0R75DEIiOHfY5 EViF1CVo/kpW4J3j3IS4RJlVmPbxL2UClAa7Vg9/z5dkuosRHRTVxdcPB4z3SjJCBZ7dUo3GpAq 74GHlOV9yNPXB5VjDSPKEds9yYRy9c+44VGtmKxNAUBhCBJxwQPcb6wIcNvO27WVOZpYvbzamLc 30PjGfsUiWxGN5uukY0/ckbaiG4dAIAPEo/KMSr/hNLub8qeGb/aSDQeu6CE+XPZqzPl1xtqHj9 L7vkoaCthNao7p9MqU/e6qIIXd8gDyd4llaE0p2GQBBzc+FTEiugOeUj8qUCemSX2UK9Ykiy0Rt 1tlwqyKloM/PgeSniTn79DIp3Uli7PmcwSwFFwomCXODyt8mGRBPw94d4JOAshi4fsjy+LsFTua Zx1eyKoK6bRm++A== X-Developer-Key: i=keescook@chromium.org; a=openpgp; fpr=A5C3F68F229DD60F723E6E138972F4DFDC6DC026 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: Alexander Viro Cc: Christian Brauner Cc: Jan Kara Cc: linux-fsdevel@vger.kernel.org Signed-off-by: Kees Cook Reviewed-by: Jan Kara --- fs/remap_range.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/remap_range.c b/fs/remap_range.c index f8c1120b8311..15e91bf2c5e3 100644 --- a/fs/remap_range.c +++ b/fs/remap_range.c @@ -45,7 +45,7 @@ static int generic_remap_checks(struct file *file_in, loff_t pos_in, return -EINVAL; /* Ensure offsets don't wrap. */ - if (pos_in + count < pos_in || pos_out + count < pos_out) + if (add_would_overflow(pos_in, count) || add_would_overflow(pos_out, count)) return -EINVAL; size_in = i_size_read(inode_in);