On Wed, 31 Jan 2024 at 00:46, Kees Cook wrote:
>
> The kernel hardening efforts have continued to depend more and more
> heavily on UBSAN, so make an actual MAINTAINERS entry for it.
>
> Cc: Andrey Ryabinin
> Cc: Marco Elver
> Cc: Andrey Konovalov
> Signed-off-by: Kees Cook
> ---
> Hi! I figur
On Wed, Jan 31, 2024 at 7:53 AM Kees Cook wrote:
>
> Using sizeof(dst) for the "size" argument in strscpy() is the
> overwhelmingly common case. Instead of requiring this everywhere, allow a
> 2-argument version to be used that will use the sizeof() internally. There
> are other functions in the k
Queued, thanks.
Huacai
On Wed, Jan 31, 2024 at 7:31 AM Kees Cook wrote:
>
> The vDSO executes in userspace, so the kernel's UBSAN should not
> instrument it. Solves these kind of build errors:
>
> loongarch64-linux-ld: arch/loongarch/vdso/vgettimeofday.o: in function
> `vdso_shift_ns':
> li
On Wed, Jan 31, 2024 at 02:41:16AM +0100, Andrey Konovalov wrote:
> On Wed, Jan 31, 2024 at 12:46 AM Kees Cook wrote:
> >
> > The kernel hardening efforts have continued to depend more and more
> > heavily on UBSAN, so make an actual MAINTAINERS entry for it.
> >
> > Cc: Andrey Ryabinin
> > Cc: M
Using sizeof(dst) for the "size" argument in strscpy() is the
overwhelmingly common case. Instead of requiring this everywhere, allow a
2-argument version to be used that will use the sizeof() internally. There
are other functions in the kernel with optional arguments[1], so this
isn't unprecedente
On Wed, Jan 31, 2024 at 12:46 AM Kees Cook wrote:
>
> The kernel hardening efforts have continued to depend more and more
> heavily on UBSAN, so make an actual MAINTAINERS entry for it.
>
> Cc: Andrey Ryabinin
> Cc: Marco Elver
> Cc: Andrey Konovalov
> Signed-off-by: Kees Cook
> ---
> Hi! I fi
The kernel hardening efforts have continued to depend more and more
heavily on UBSAN, so make an actual MAINTAINERS entry for it.
Cc: Andrey Ryabinin
Cc: Marco Elver
Cc: Andrey Konovalov
Signed-off-by: Kees Cook
---
Hi! I figured since I've been carrying UBSAN changes more and more lately,
I w
The vDSO executes in userspace, so the kernel's UBSAN should not
instrument it. Solves these kind of build errors:
loongarch64-linux-ld: arch/loongarch/vdso/vgettimeofday.o: in function
`vdso_shift_ns':
lib/vdso/gettimeofday.c:23:(.text+0x3f8): undefined reference to
`__ubsan_handle_shift_ou
The early boot stub for sh had UBSan instrumentation present where it is
not supported. Disable it for this part of the build.
sh4-linux-ld: arch/sh/boot/compressed/misc.o: in function
`zlib_inflate_table':
misc.c:(.text+0x670): undefined reference to
`__ubsan_handle_shift_out_of_bounds'
Re
The check_*_overflow() helpers will return results with potentially
wrapped-around values. These values have always been checked by the
selftests, so avoid the confusing language in the kern-doc. The idea of
"safe for use" was relative to the expectation of whether or not the
caller wants a wrapped
This allows replacements of the idioms "var += offset" and "var -= offset"
with the inc_wrap() and dec_wrap() helpers respectively. They will avoid
wrap-around sanitizer instrumentation.
Add to the selftests to validate behavior and lack of side-effects.
Cc: Rasmus Villemoes
Cc: Mark Rutland
Cc
Provide helpers that will perform wrapping addition, subtraction, or
multiplication without tripping the arithmetic wrap-around sanitizers. The
first argument is the type under which the wrap-around should happen
with. In other words, these two calls will get very different results:
mul_wr
For instances where only the overflow needs to be checked (and the sum
isn't used), provide the new helper add_would_overflow(), which is
a wrapper for check_add_overflow().
Cc: Rasmus Villemoes
Cc: "Gustavo A. R. Silva"
Cc: Justin Stitt
Cc: linux-hardening@vger.kernel.org
Signed-off-by: Kees C
Hi,
v2:
- Define inc/dec_wrap() in terms of add/sub_wrap() and avoid side-effects
(Rasmus)
- Fix various typos (Rasmus)
- Add selftests for all the new helpers
v1: https://lore.kernel.org/lkml/20240129182845.work.694-k...@kernel.org/
In preparation for gaining instrumentation for signed[1], u
The check_add_overflow() helper is mostly a wrapper around
__builtin_add_overflow(), but GCC and Clang refuse to operate on pointer
arguments that would normally be allowed if the addition were open-coded.
For example, we have many places where pointer overflow is tested:
struct foo *ptr;
On Tue, Jan 30, 2024 at 08:54:00PM +0100, Uladzislau Rezki wrote:
> On Tue, Jan 30, 2024 at 06:55:57PM +, 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
On Tue, Jan 30, 2024 at 04:18:42PM +0100, Rasmus Villemoes wrote:
> So here scnprint() would have returned 1, leaving size at 1. scnprintf()
> has the invariant that, for non-zero size, the return value is strictly
> less than that size, so when passed a size of 1, all subsequent calls
> return 0 (
On Tue, Jan 30, 2024 at 06:55:57PM +, 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
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
>
> Not
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
>
> Not
On 1/28/24 05:52, Erick Archer wrote:
This is an effort to get rid of all multiplications from allocation
functions in order to prevent integer overflows [1].
Here the multiplication is obviously safe because the "channels"
member can only be 8 or 2. This value is set when the "vendor_data"
s
There is an ongoing effort to replace the use of {v}snprintf() variants
with safer alternatives - for a more in depth view, see Jon's write-up
on LWN [0] and/or Alex's on the Kernel Self Protection Project [1].
Whist executing the task, it quickly became apparent that the initial
thought of simply
On Tue, 30 Jan 2024, Rasmus Villemoes wrote:
> On 30/01/2024 16.07, Lee Jones wrote:
> > On Mon, 29 Jan 2024, Lee Jones wrote:
> >
> >> On Mon, 29 Jan 2024, David Laight wrote:
> >>
> >>> ...
> > I'm sure that the safest return for 'truncated' is the buffer length.
> > The a series of sta
On 30/01/2024 16.07, Lee Jones wrote:
> On Mon, 29 Jan 2024, Lee Jones wrote:
>
>> On Mon, 29 Jan 2024, David Laight wrote:
>>
>>> ...
> I'm sure that the safest return for 'truncated' is the buffer length.
> The a series of statements like:
> buf += xxx(buf, buf_end - buf, .);
>
On Mon, 29 Jan 2024, Lee Jones wrote:
> On Mon, 29 Jan 2024, David Laight wrote:
>
> > ...
> > > > I'm sure that the safest return for 'truncated' is the buffer length.
> > > > The a series of statements like:
> > > > buf += xxx(buf, buf_end - buf, .);
> > > > can all be called with a
On 1/28/24 5:27 AM, Erick Archer wrote:
This is an effort to get rid of all multiplications from allocation
functions in order to prevent integer overflows [1].
Here the multiplication is obviously safe because the "event_rings"
member never can have a value greater than 255 (8 bits). This membe
On Mon 29-01-24 10:40:15, Kees Cook wrote:
> 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
On Mon, 29 Jan 2024 10:40:15 -0800, Kees Cook wrote:
> 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.
On Mon, 29 Jan 2024 10:37:29 -0800, Kees Cook wrote:
> The loop counter "i" in copy_compat_iovec_from_user() is an int, but
> because the nr_segs argument is unsigned long, the signed overflow
> sanitizer got worried "i" could wrap around. Instead of making "i" an
> unsigned long (which may enlarge
On Sun, Jan 28, 2024 at 12:27:22PM +0100, Erick Archer wrote:
> This is an effort to get rid of all multiplications from allocation
> functions in order to prevent integer overflows [1].
>
> Here the multiplication is obviously safe because the "event_rings"
> member never can have a value greater
On Mon, Jan 22, 2024 at 10:15:20AM +0300, Dan Carpenter wrote:
> This code does not have an integer overflow, but it might have a
> different memory corruption bug.
>
> On Sat, Jan 20, 2024 at 04:25:18PM +0100, Erick Archer wrote:
> > As noted in the "Deprecated Interfaces, Language Features, Attr
Helge Deller writes:
> On 1/29/24 15:58, Guenter Roeck wrote:
>> On 1/29/24 03:06, Geert Uytterhoeven wrote:
>> [ ... ]
>>> parisc-gcc1[23]/parisc-{allmod,def}config
>>>
>>> + /kisskb/src/drivers/hwmon/pc87360.c: error: writing 1 byte into a
>>> region of size 0 [-Werror=stringop-overflow=]
32 matches
Mail list logo
