From: Kees Cook <keescook@chromium.org> To: Nick Desaulniers <ndesaulniers@google.com> Cc: linux-hardening@vger.kernel.org, "Gustavo A. R. Silva" <gustavoars@kernel.org>, Keith Packard <keithpac@amazon.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Andrew Morton <akpm@linux-foundation.org>, linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org, netdev@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-staging@lists.linux.dev, linux-block@vger.kernel.org, linux-kbuild@vger.kernel.org, clang-built-linux@googlegroups.com Subject: Re: [PATCH 34/64] fortify: Detect struct member overflows in memcpy() at compile-time Date: Tue, 27 Jul 2021 18:47:52 -0700 [thread overview] Message-ID: <202107271830.3DB03F3CF@keescook> (raw) In-Reply-To: <CAKwvOdknit8DtWaFvLupmNEebjbwVa6R3xiGc2D4AqB_6+i52g@mail.gmail.com> On Tue, Jul 27, 2021 at 03:43:27PM -0700, Nick Desaulniers wrote: > On Tue, Jul 27, 2021 at 2:17 PM Kees Cook <keescook@chromium.org> wrote: > > > > To accelerate the review of potential run-time false positives, it's > > also worth noting that it is possible to partially automate checking > > by examining memcpy() buffer argument fields to see if they have > > a neighboring. It is reasonable to expect that the vast majority of > > a neighboring...field? Whoops, sorry, this should say "array member". I've fixed this to read: To accelerate the review of potential run-time false positives, it's also worth noting that it is possible to partially automate checking by examining the memcpy() buffer argument to check for the destination struct member having a neighboring array member. It is reasonable to expect that the vast majority of run-time false positives would look like the already evaluated and fixed compile-time false positives, where the most common pattern is neighboring arrays. (And, FWIW, several of the compile-time fixes were actual bugs.) > > diff --git a/include/linux/fortify-string.h b/include/linux/fortify-string.h > > index 7e67d02764db..5e79e626172b 100644 > > --- a/include/linux/fortify-string.h > > +++ b/include/linux/fortify-string.h > > @@ -2,13 +2,17 @@ > > #ifndef _LINUX_FORTIFY_STRING_H_ > > #define _LINUX_FORTIFY_STRING_H_ > > > > +#include <linux/bug.h> > > What are you using from linux/bug.h here? Thanks; yes, that should have been added in patch 64, when the WARN_ONCE() use is introduced: https://lore.kernel.org/lkml/20210727205855.411487-65-keescook@chromium.org/ > > [...] > > +#define __fortify_memcpy_chk(p, q, size, p_size, q_size, \ > > + p_size_field, q_size_field, op) ({ \ > > + size_t __fortify_size = (size_t)(size); \ > > + fortify_memcpy_chk(__fortify_size, p_size, q_size, \ > > + p_size_field, q_size_field, #op); \ > > + __underlying_##op(p, q, __fortify_size); \ > > +}) > > + > > +/* > > + * __builtin_object_size() must be captured here to avoid evaluating argument > > + * side-effects further into the macro layers. > > + */ > > +#define memcpy(p, q, s) __fortify_memcpy_chk(p, q, s, \ > > + __builtin_object_size(p, 0), __builtin_object_size(q, 0), \ > > + __builtin_object_size(p, 1), __builtin_object_size(q, 1), \ > > + memcpy) > > Are there other macro expansion sites for `__fortify_memcpy_chk`, > perhaps later in this series? I don't understand why `memcpy` is > passed as `func` to `fortify_panic()` rather than continuing to use > `__func__`? Yes, memmove() follows exactly the same pattern. Rather than refactoring the declaration in that patch, this felt cleaner. https://lore.kernel.org/lkml/20210727205855.411487-36-keescook@chromium.org/ > > [...] > > * @count: The number of bytes to copy > > * @pad: Character to use for padding if space is left in destination. > > */ > > -static inline void memcpy_and_pad(void *dest, size_t dest_len, > > - const void *src, size_t count, int pad) > > +static __always_inline void memcpy_and_pad(void *dest, size_t dest_len, > > + const void *src, size_t count, > > + int pad) > > Why __always_inline here? Without it, we run the risk of it being made out of line, and potentially losing access to the __builtin_object_size() checking of arguments. Though given some of the Clang bugs, it's possible this needs to be strictly converted into a macro. > > [...] > > #ifdef CONFIG_FORTIFY_SOURCE > > +/* These are placeholders for fortify compile-time warnings. */ > > +void __read_overflow2_field(void) { } > > +EXPORT_SYMBOL(__read_overflow2_field); > > +void __write_overflow_field(void) { } > > +EXPORT_SYMBOL(__write_overflow_field); > > + > > Don't we rely on these being undefined for Clang to produce a linkage > failure (until https://reviews.llvm.org/D106030 has landed)? By > providing a symbol definition we can link against, I don't think > __compiletime_{warning|error} will warn at all with Clang? This was intentional because I explicitly do not want to break the build for new warnings, and there is no way currently for Clang to _warn_ (rather than fail to link). This could be adjusted to break only Clang's builds, but at this point, it seemed best. > > [...] > > +// SPDX-License-Identifier: GPL-2.0-only > > +#define TEST \ > > + memcpy(instance.buf, large, sizeof(instance.buf) + 1) > > + > > +#include "test_fortify.h" > > -- > > I haven't read the whole series yet, but I assume test_fortify.h was > provided earlier in the series? Yup, it's part of the compile-time tests in patch 32: https://lore.kernel.org/lkml/20210727205855.411487-33-keescook@chromium.org/ -Kees -- Kees Cook
WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org> To: Nick Desaulniers <ndesaulniers@google.com> Cc: linux-kbuild@vger.kernel.org, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, linux-staging@lists.linux.dev, linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, "Gustavo A. R. Silva" <gustavoars@kernel.org>, linux-block@vger.kernel.org, clang-built-linux@googlegroups.com, Keith Packard <keithpac@amazon.com>, linux-hardening@vger.kernel.org, netdev@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org> Subject: Re: [PATCH 34/64] fortify: Detect struct member overflows in memcpy() at compile-time Date: Tue, 27 Jul 2021 18:47:52 -0700 [thread overview] Message-ID: <202107271830.3DB03F3CF@keescook> (raw) In-Reply-To: <CAKwvOdknit8DtWaFvLupmNEebjbwVa6R3xiGc2D4AqB_6+i52g@mail.gmail.com> On Tue, Jul 27, 2021 at 03:43:27PM -0700, Nick Desaulniers wrote: > On Tue, Jul 27, 2021 at 2:17 PM Kees Cook <keescook@chromium.org> wrote: > > > > To accelerate the review of potential run-time false positives, it's > > also worth noting that it is possible to partially automate checking > > by examining memcpy() buffer argument fields to see if they have > > a neighboring. It is reasonable to expect that the vast majority of > > a neighboring...field? Whoops, sorry, this should say "array member". I've fixed this to read: To accelerate the review of potential run-time false positives, it's also worth noting that it is possible to partially automate checking by examining the memcpy() buffer argument to check for the destination struct member having a neighboring array member. It is reasonable to expect that the vast majority of run-time false positives would look like the already evaluated and fixed compile-time false positives, where the most common pattern is neighboring arrays. (And, FWIW, several of the compile-time fixes were actual bugs.) > > diff --git a/include/linux/fortify-string.h b/include/linux/fortify-string.h > > index 7e67d02764db..5e79e626172b 100644 > > --- a/include/linux/fortify-string.h > > +++ b/include/linux/fortify-string.h > > @@ -2,13 +2,17 @@ > > #ifndef _LINUX_FORTIFY_STRING_H_ > > #define _LINUX_FORTIFY_STRING_H_ > > > > +#include <linux/bug.h> > > What are you using from linux/bug.h here? Thanks; yes, that should have been added in patch 64, when the WARN_ONCE() use is introduced: https://lore.kernel.org/lkml/20210727205855.411487-65-keescook@chromium.org/ > > [...] > > +#define __fortify_memcpy_chk(p, q, size, p_size, q_size, \ > > + p_size_field, q_size_field, op) ({ \ > > + size_t __fortify_size = (size_t)(size); \ > > + fortify_memcpy_chk(__fortify_size, p_size, q_size, \ > > + p_size_field, q_size_field, #op); \ > > + __underlying_##op(p, q, __fortify_size); \ > > +}) > > + > > +/* > > + * __builtin_object_size() must be captured here to avoid evaluating argument > > + * side-effects further into the macro layers. > > + */ > > +#define memcpy(p, q, s) __fortify_memcpy_chk(p, q, s, \ > > + __builtin_object_size(p, 0), __builtin_object_size(q, 0), \ > > + __builtin_object_size(p, 1), __builtin_object_size(q, 1), \ > > + memcpy) > > Are there other macro expansion sites for `__fortify_memcpy_chk`, > perhaps later in this series? I don't understand why `memcpy` is > passed as `func` to `fortify_panic()` rather than continuing to use > `__func__`? Yes, memmove() follows exactly the same pattern. Rather than refactoring the declaration in that patch, this felt cleaner. https://lore.kernel.org/lkml/20210727205855.411487-36-keescook@chromium.org/ > > [...] > > * @count: The number of bytes to copy > > * @pad: Character to use for padding if space is left in destination. > > */ > > -static inline void memcpy_and_pad(void *dest, size_t dest_len, > > - const void *src, size_t count, int pad) > > +static __always_inline void memcpy_and_pad(void *dest, size_t dest_len, > > + const void *src, size_t count, > > + int pad) > > Why __always_inline here? Without it, we run the risk of it being made out of line, and potentially losing access to the __builtin_object_size() checking of arguments. Though given some of the Clang bugs, it's possible this needs to be strictly converted into a macro. > > [...] > > #ifdef CONFIG_FORTIFY_SOURCE > > +/* These are placeholders for fortify compile-time warnings. */ > > +void __read_overflow2_field(void) { } > > +EXPORT_SYMBOL(__read_overflow2_field); > > +void __write_overflow_field(void) { } > > +EXPORT_SYMBOL(__write_overflow_field); > > + > > Don't we rely on these being undefined for Clang to produce a linkage > failure (until https://reviews.llvm.org/D106030 has landed)? By > providing a symbol definition we can link against, I don't think > __compiletime_{warning|error} will warn at all with Clang? This was intentional because I explicitly do not want to break the build for new warnings, and there is no way currently for Clang to _warn_ (rather than fail to link). This could be adjusted to break only Clang's builds, but at this point, it seemed best. > > [...] > > +// SPDX-License-Identifier: GPL-2.0-only > > +#define TEST \ > > + memcpy(instance.buf, large, sizeof(instance.buf) + 1) > > + > > +#include "test_fortify.h" > > -- > > I haven't read the whole series yet, but I assume test_fortify.h was > provided earlier in the series? Yup, it's part of the compile-time tests in patch 32: https://lore.kernel.org/lkml/20210727205855.411487-33-keescook@chromium.org/ -Kees -- Kees Cook
next prev parent reply other threads:[~2021-07-28 1:47 UTC|newest] Thread overview: 308+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-27 20:57 [PATCH 00/64] Introduce strict memcpy() bounds checking Kees Cook 2021-07-27 20:57 ` Kees Cook 2021-07-27 20:57 ` [PATCH 01/64] media: omap3isp: Extract struct group for memcpy() region Kees Cook 2021-07-27 20:57 ` Kees Cook 2021-07-28 0:55 ` Gustavo A. R. Silva 2021-07-28 0:55 ` Gustavo A. R. Silva 2021-07-28 1:50 ` Kees Cook 2021-07-28 1:50 ` Kees Cook 2021-07-28 8:59 ` David Sterba 2021-07-28 8:59 ` David Sterba 2021-07-28 9:14 ` Dan Carpenter 2021-07-28 21:37 ` Bart Van Assche 2021-07-28 21:37 ` David Sterba 2021-07-28 21:37 ` David Sterba 2021-07-29 5:56 ` Greg Kroah-Hartman 2021-07-29 8:20 ` Dan Carpenter 2021-07-29 8:20 ` Dan Carpenter 2021-07-30 6:00 ` Kees Cook 2021-07-30 6:00 ` Kees Cook 2021-07-30 8:38 ` David Sterba 2021-07-30 8:38 ` David Sterba 2021-07-30 9:00 ` Dan Carpenter 2021-07-30 16:44 ` Kees Cook 2021-07-30 17:08 ` Nick Desaulniers 2021-07-30 17:08 ` Nick Desaulniers 2021-07-30 17:08 ` Nick Desaulniers 2021-07-30 19:18 ` Kees Cook 2021-07-27 20:57 ` [PATCH 02/64] mac80211: Use flex-array for radiotap header bitmap Kees Cook 2021-07-27 20:57 ` Kees Cook 2021-07-28 7:35 ` Dan Carpenter 2021-07-28 7:35 ` Dan Carpenter 2021-07-28 9:23 ` David Sterba 2021-07-28 9:23 ` David Sterba 2021-07-28 21:54 ` Kees Cook 2021-07-29 10:45 ` David Sterba 2021-07-29 10:45 ` David Sterba 2021-07-30 6:06 ` Kees Cook 2021-07-28 21:20 ` Kees Cook 2021-07-28 21:20 ` Kees Cook 2021-07-28 23:14 ` Kees Cook 2021-07-28 23:14 ` Kees Cook 2021-07-28 23:33 ` Kees Cook 2021-07-28 23:33 ` Kees Cook 2021-07-29 8:25 ` Dan Carpenter 2021-07-29 8:25 ` Dan Carpenter 2021-07-27 20:57 ` [PATCH 03/64] rpmsg: glink: Replace strncpy() with strscpy_pad() Kees Cook 2021-07-27 20:57 ` Kees Cook 2021-07-28 2:07 ` Gustavo A. R. Silva 2021-07-28 2:07 ` Gustavo A. R. Silva 2021-07-27 20:57 ` [PATCH 04/64] stddef: Introduce struct_group() helper macro Kees Cook 2021-07-27 20:57 ` Kees Cook 2021-07-28 2:32 ` Gustavo A. R. Silva 2021-07-28 2:32 ` Gustavo A. R. Silva 2021-07-28 10:54 ` Rasmus Villemoes 2021-07-28 10:54 ` Rasmus Villemoes 2021-07-28 21:59 ` Kees Cook 2021-07-28 21:59 ` Kees Cook 2021-07-30 22:19 ` Williams, Dan J 2021-07-30 22:19 ` Williams, Dan J 2021-07-31 2:59 ` Kees Cook 2021-07-31 2:59 ` Kees Cook 2021-07-31 5:24 ` Rasmus Villemoes 2021-07-31 15:10 ` Kees Cook 2021-07-27 20:57 ` [PATCH 05/64] skbuff: Switch structure bounds to struct_group() Kees Cook 2021-07-27 20:57 ` Kees Cook 2021-07-28 3:50 ` Gustavo A. R. Silva 2021-07-28 3:50 ` Gustavo A. R. Silva 2021-07-27 20:57 ` [PATCH 06/64] bnxt_en: Use struct_group_attr() for memcpy() region Kees Cook 2021-07-27 20:57 ` Kees Cook 2021-07-28 1:03 ` Michael Chan 2021-07-28 1:03 ` Michael Chan 2021-07-28 1:03 ` Michael Chan 2021-07-28 4:45 ` Gustavo A. R. Silva 2021-07-28 4:45 ` Gustavo A. R. Silva 2021-07-27 20:57 ` [PATCH 07/64] staging: rtl8192e: Use struct_group() " Kees Cook 2021-07-27 20:57 ` Kees Cook 2021-07-27 22:30 ` Larry Finger 2021-07-27 22:30 ` Larry Finger 2021-07-28 5:45 ` Greg Kroah-Hartman 2021-07-28 5:45 ` Greg Kroah-Hartman 2021-07-27 20:57 ` [PATCH 08/64] staging: rtl8192u: " Kees Cook 2021-07-27 20:57 ` Kees Cook 2021-07-28 5:45 ` Greg Kroah-Hartman 2021-07-28 5:45 ` Greg Kroah-Hartman 2021-07-27 20:58 ` [PATCH 09/64] staging: rtl8723bs: Avoid field-overflowing memcpy() Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-28 5:46 ` Greg Kroah-Hartman 2021-07-28 5:46 ` Greg Kroah-Hartman 2021-07-27 20:58 ` [PATCH 10/64] lib80211: Use struct_group() for memcpy() region Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-28 5:52 ` Greg Kroah-Hartman 2021-07-28 5:52 ` Greg Kroah-Hartman 2021-08-13 8:04 ` Johannes Berg 2021-08-13 8:04 ` Johannes Berg 2021-08-13 15:49 ` Kees Cook 2021-08-13 19:44 ` Johannes Berg 2021-08-13 19:44 ` Johannes Berg 2021-07-27 20:58 ` [PATCH 11/64] net/mlx5e: Avoid field-overflowing memcpy() Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-27 20:58 ` [PATCH 12/64] mwl8k: Use struct_group() for memcpy() region Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-27 20:58 ` [PATCH 13/64] libertas: " Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-27 20:58 ` [PATCH 14/64] libertas_tf: " Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-27 20:58 ` [PATCH 15/64] ipw2x00: " Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-28 18:55 ` Stanislav Yakovlev 2021-07-28 18:55 ` Stanislav Yakovlev 2021-07-28 18:55 ` Stanislav Yakovlev 2021-07-27 20:58 ` [PATCH 16/64] thermal: intel: int340x_thermal: " Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-27 20:58 ` [PATCH 17/64] iommu/amd: " Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-27 20:58 ` [PATCH 18/64] cxgb3: " Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-27 20:58 ` [PATCH 19/64] ip: Use struct_group() for memcpy() regions Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-28 5:55 ` Greg Kroah-Hartman 2021-07-28 5:55 ` Greg Kroah-Hartman 2021-07-28 6:14 ` Gustavo A. R. Silva 2021-07-28 6:14 ` Gustavo A. R. Silva 2021-07-28 6:19 ` Greg Kroah-Hartman 2021-07-28 6:19 ` Greg Kroah-Hartman 2021-07-28 6:31 ` Gustavo A. R. Silva 2021-07-28 6:31 ` Gustavo A. R. Silva 2021-07-28 6:37 ` Gustavo A. R. Silva 2021-07-28 6:37 ` Gustavo A. R. Silva 2021-07-28 6:41 ` Greg Kroah-Hartman 2021-07-28 6:41 ` Greg Kroah-Hartman 2021-07-28 21:01 ` Kees Cook 2021-07-28 21:01 ` Kees Cook 2021-07-29 1:59 ` Bart Van Assche 2021-07-29 1:59 ` Bart Van Assche 2021-07-27 20:58 ` [PATCH 20/64] intersil: Use struct_group() for memcpy() region Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-27 20:58 ` [PATCH 21/64] cxgb4: " Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-27 20:58 ` [PATCH 22/64] bnx2x: " Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-27 20:58 ` [PATCH 23/64] drm/amd/pm: " Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-30 2:07 ` Alex Deucher 2021-07-30 2:07 ` Alex Deucher 2021-07-30 2:07 ` Alex Deucher 2021-07-27 20:58 ` [PATCH 24/64] staging: wlan-ng: " Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-28 5:45 ` Greg Kroah-Hartman 2021-07-28 5:45 ` Greg Kroah-Hartman 2021-07-27 20:58 ` [PATCH 25/64] drm/mga/mga_ioc32: " Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-28 5:56 ` Greg Kroah-Hartman 2021-07-28 5:56 ` Greg Kroah-Hartman 2021-07-29 12:11 ` Daniel Vetter 2021-07-31 4:20 ` Kees Cook 2021-07-27 20:58 ` [PATCH 26/64] net/mlx5e: " Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-27 20:58 ` [PATCH 27/64] HID: cp2112: " Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-27 20:58 ` [PATCH 28/64] compiler_types.h: Remove __compiletime_object_size() Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-27 20:58 ` [PATCH 29/64] lib/string: Move helper functions out of string.c Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-27 20:58 ` [PATCH 30/64] fortify: Move remaining fortify helpers into fortify-string.h Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-27 20:58 ` [PATCH 31/64] fortify: Explicitly disable Clang support Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-27 21:18 ` Nathan Chancellor 2021-07-27 21:18 ` Nathan Chancellor 2021-07-27 21:47 ` Kees Cook 2021-07-27 21:47 ` Kees Cook 2021-07-27 20:58 ` [PATCH 32/64] fortify: Add compile-time FORTIFY_SOURCE tests Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-27 20:58 ` [PATCH 33/64] lib: Introduce CONFIG_TEST_MEMCPY Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-27 23:31 ` Bart Van Assche 2021-07-27 23:31 ` Bart Van Assche 2021-07-27 23:33 ` Randy Dunlap 2021-07-27 23:33 ` Randy Dunlap 2021-07-28 1:30 ` Kees Cook 2021-07-28 1:30 ` Kees Cook 2021-07-27 20:58 ` [PATCH 34/64] fortify: Detect struct member overflows in memcpy() at compile-time Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-27 22:43 ` Nick Desaulniers 2021-07-27 22:43 ` Nick Desaulniers 2021-07-27 22:43 ` Nick Desaulniers 2021-07-28 1:47 ` Kees Cook [this message] 2021-07-28 1:47 ` Kees Cook 2021-07-28 0:34 ` kernel test robot 2021-07-28 3:24 ` kernel test robot 2021-07-28 11:19 ` Rasmus Villemoes 2021-07-28 11:19 ` Rasmus Villemoes 2021-07-30 2:39 ` Kees Cook 2021-07-30 2:39 ` Kees Cook 2021-07-28 11:44 ` kernel test robot 2021-07-28 15:22 ` kernel test robot 2021-07-28 22:06 ` kernel test robot 2021-07-27 20:58 ` [PATCH 35/64] fortify: Detect struct member overflows in memmove() " Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-08-02 5:08 ` kernel test robot 2021-07-27 20:58 ` [PATCH 36/64] scsi: ibmvscsi: Avoid multi-field memset() overflow by aiming at srp Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-28 1:39 ` Martin K. Petersen 2021-07-28 1:39 ` Martin K. Petersen 2021-07-28 18:57 ` Kees Cook 2021-07-28 18:57 ` Kees Cook 2021-07-29 3:35 ` Martin K. Petersen 2021-07-29 3:35 ` Martin K. Petersen 2021-07-30 19:11 ` Tyrel Datwyler 2021-07-30 18:16 ` Tyrel Datwyler 2021-07-27 20:58 ` [PATCH 37/64] string.h: Introduce memset_after() for wiping trailing members/padding Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-27 20:58 ` [PATCH 38/64] xfrm: Use memset_after() to clear padding Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-27 20:58 ` [PATCH 39/64] mac80211: Use memset_after() to clear tx status Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-31 15:55 ` Kees Cook 2021-08-13 7:40 ` Johannes Berg 2021-08-13 7:40 ` Johannes Berg 2021-08-13 16:08 ` Kees Cook 2021-08-13 18:19 ` Johannes Berg 2021-08-13 18:19 ` Johannes Berg 2021-08-13 7:41 ` Johannes Berg 2021-08-13 7:41 ` Johannes Berg 2021-07-27 20:58 ` [PATCH 40/64] net: 802: Use memset_after() to clear struct fields Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-27 20:58 ` [PATCH 41/64] net: dccp: Use memset_after() for TP zeroing Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-27 20:58 ` [PATCH 42/64] net: qede: Use memset_after() for counters Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-31 16:07 ` Kees Cook 2021-07-27 20:58 ` [PATCH 43/64] ath11k: Use memset_after() for clearing queue descriptors Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-27 20:58 ` [PATCH 44/64] iw_cxgb4: Use memset_after() for cpl_t5_pass_accept_rpl Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-27 20:58 ` [PATCH 45/64] intel_th: msu: Use memset_after() for clearing hw header Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-27 20:58 ` [PATCH 46/64] IB/mthca: Use memset_after() for clearing mpt_entry Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-27 20:58 ` [PATCH 47/64] btrfs: Use memset_after() to clear end of struct Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-28 9:42 ` David Sterba 2021-07-28 9:42 ` David Sterba 2021-07-28 21:56 ` Kees Cook 2021-07-29 10:33 ` David Sterba 2021-07-29 10:33 ` David Sterba 2021-07-31 15:25 ` Kees Cook 2021-08-09 11:20 ` David Sterba 2021-07-27 20:58 ` [PATCH 48/64] drbd: Use struct_group() to zero algs Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-28 21:45 ` Bart Van Assche 2021-07-28 21:45 ` Bart Van Assche 2021-07-30 2:31 ` Kees Cook 2021-07-30 2:31 ` Kees Cook 2021-07-30 2:57 ` Bart Van Assche 2021-07-30 2:57 ` Bart Van Assche 2021-07-30 9:25 ` Lars Ellenberg 2021-07-30 9:25 ` Lars Ellenberg 2021-07-30 15:32 ` Nick Desaulniers 2021-07-30 15:32 ` Nick Desaulniers 2021-07-27 20:58 ` [PATCH 49/64] cm4000_cs: Use struct_group() to zero struct cm4000_dev region Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-28 5:48 ` Greg Kroah-Hartman 2021-07-28 5:48 ` Greg Kroah-Hartman 2021-07-27 20:58 ` [PATCH 50/64] KVM: x86: Use struct_group() to zero decode cache Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-27 20:58 ` [PATCH 51/64] tracing: Use struct_group() to zero struct trace_iterator Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-27 20:58 ` [PATCH 52/64] dm integrity: Use struct_group() to zero struct journal_sector Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-27 20:58 ` [PATCH 53/64] HID: roccat: Use struct_group() to zero kone_mouse_event Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-27 20:58 ` [PATCH 54/64] ipv6: Use struct_group() to zero rt6_info Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-29 18:58 ` Jakub Kicinski 2021-07-29 18:58 ` Jakub Kicinski 2021-07-31 15:01 ` Kees Cook 2021-07-27 20:58 ` [PATCH 55/64] RDMA/mlx5: Use struct_group() to zero struct mlx5_ib_mr Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-27 20:58 ` [PATCH 56/64] ethtool: stats: Use struct_group() to clear all stats at once Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-27 20:58 ` [PATCH 57/64] netfilter: conntrack: Use struct_group() to zero struct nf_conn Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-27 20:58 ` [PATCH 58/64] powerpc: Split memset() to avoid multi-field overflow Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-08-05 11:36 ` Michael Ellerman 2021-07-27 20:58 ` [PATCH 59/64] fortify: Detect struct member overflows in memset() at compile-time Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-28 2:59 ` kernel test robot 2021-07-28 17:18 ` kernel test robot 2021-07-27 20:58 ` [PATCH 60/64] fortify: Work around Clang inlining bugs Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-27 20:58 ` [PATCH 61/64] Makefile: Enable -Warray-bounds Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-27 20:58 ` [PATCH 62/64] netlink: Avoid false-positive memcpy() warning Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-28 5:49 ` Greg Kroah-Hartman 2021-07-28 5:49 ` Greg Kroah-Hartman 2021-07-28 11:24 ` Rasmus Villemoes 2021-07-28 11:24 ` Rasmus Villemoes 2021-07-30 1:39 ` Kees Cook 2021-07-30 1:39 ` Kees Cook 2021-07-30 1:41 ` Kees Cook 2021-07-30 1:41 ` Kees Cook 2021-07-27 20:58 ` [PATCH 63/64] iwlwifi: dbg_ini: Split memcpy() to avoid multi-field write Kees Cook 2021-07-27 20:58 ` Kees Cook 2021-07-27 20:58 ` [PATCH 64/64] fortify: Add run-time WARN for cross-field memcpy() Kees Cook 2021-07-27 20:58 ` 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=202107271830.3DB03F3CF@keescook \ --to=keescook@chromium.org \ --cc=akpm@linux-foundation.org \ --cc=clang-built-linux@googlegroups.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=gregkh@linuxfoundation.org \ --cc=gustavoars@kernel.org \ --cc=keithpac@amazon.com \ --cc=linux-block@vger.kernel.org \ --cc=linux-hardening@vger.kernel.org \ --cc=linux-kbuild@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-staging@lists.linux.dev \ --cc=linux-wireless@vger.kernel.org \ --cc=ndesaulniers@google.com \ --cc=netdev@vger.kernel.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.