Hi,
It was recently pointed out[1] that x86_64 brk entropy was not great,
and that on all architectures the brk can (when the random offset is 0)
be immediately adjacent to .bss, leaving no gap that could stop linear
overflows from the .bss. Address both issues.
-Kees
Link:
In commit c1d171a00294 ("x86: randomize brk"), arch_randomize_brk() was
defined to use a 32MB range (13 bits of entropy), but was never increased
when moving to 64-bit. The default arch_randomize_brk() uses 32MB for
32-bit tasks, and 1GB (18 bits of entropy) for 64-bit tasks. Update
x86_64 to
Currently the brk starts its randomization immediately after .bss,
which means there is a chance that when the random offset is 0, linear
overflows from .bss can reach into the brk area. Leave at least a single
page gap between .bss and brk (when it has not already been explicitly
relocated into
On Sat, Feb 10, 2024 at 01:18:35AM -0800, Kees Cook wrote:
> The vDSO (and its initial randomization) was introduced in commit
> 2aae950b21e4 ("x86_64: Add vDSO for x86-64 with
> gettimeofday/clock_gettime/getcpu"),
> but had very low entropy. The entropy was improved in commit
> 394f56fe4801
With fortify overflows able to be redirected, we can use KUnit to
exercise the overflow conditions. Add tests for every API covered by
CONFIG_FORTIFY_SOURCE, except for memset() and memcpy(), which are
special-cased for now.
Note that this makes the LKDTM FORTIFY_STR* tests obsolete, but those
Improve the reporting of buffer overflows under CONFIG_FORTIFY_SOURCE to
help accelerate debugging efforts. The calculations are all just sitting
in registers anyway, so pass them along to the function to be reported.
For example, before:
detected buffer overflow in memcpy
and after:
The standard C string APIs were not designed to have a failure mode;
they were expected to always succeed without memory safety issues.
Normally, CONFIG_FORTIFY_SOURCE will use fortify_panic() to stop
processing, as truncating a read or write may provide an even worse
system state. However, this
In preparation for KUnit testing and further improvements in fortify
failure reporting, split out the report and encode the function and access
failure (read or write overflow) into a single u8 argument. This mainly
ends up saving a tiny bit of space in the data segment. For a defconfig
with
Hi,
This series is the rest of the v2 series that was half landed last year,
and finally introduces KUnit runtime testing of the CONFIG_FORTIFY_SOURCE
APIs. Additionally FORTIFY failure messages are improved to give more
context about read/write and sizes.
-Kees
v3
- rebase (goodbye strlcpy)
In order for CI systems to notice all the skipped tests related to
CONFIG_FORTIFY_SOURCE, allow the FORTIFY_SOURCE KUnit tests to build
with or without CONFIG_FORTIFY_SOURCE.
Signed-off-by: Kees Cook
---
Cc: linux-hardening@vger.kernel.org
---
lib/Kconfig.debug | 2 +-
lib/fortify_kunit.c |
From: Kees Cook
Date: Fri, 16 Feb 2024 15:22:23 -0800
> While testing for places where zero-sized destinations were still showing
> up in the kernel, sock_copy() and inet_reqsk_clone() were found, which
> are using very specific memcpy() offsets for both avoiding a portion of
> struct sock, and
On 2/16/24 17:27, Kees Cook wrote:
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and
The struct xt_entry_target fake flexible array has not be converted to a
true flexible array, which is mainly blocked by it being both UAPI and
used in the middle of other structures. In order to properly check for
0-sized destinations in memcpy(), an exception must be made for the one
place where
FORTIFY_SOURCE has been ignoring 0-sized destinations while the kernel
code base has been converted to flexible arrays. In order to enforce
the 0-sized destinations (e.g. with __counted_by), the remaining 0-sized
destinations need to be handled. Unfortunately, struct vic_provinfo
resists full
ntfs_name::name is used as a destination in memcpy(), so it cannot be a
0-sized array any more. Convert it to a flexible array and annotated
with __counted_by, which matches the allocations.
Signed-off-by: Kees Cook
---
Cc: Anton Altaparmakov
Cc: Namjae Jeon
Cc: "Gustavo A. R. Silva"
Cc:
FORTIFY_SOURCE has been ignoring 0-sized destinations while the kernel
code base has been converted to flexible arrays. In order to enforce
the 0-sized destinations (e.g. with __counted_by), the remaining 0-sized
destinations need to be handled. Instead of converting an empty struct
into using a
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
While testing for places where zero-sized destinations were still showing
up in the kernel, sock_copy() and inet_reqsk_clone() were found, which
are using very specific memcpy() offsets for both avoiding a portion of
struct sock, and copying beyond the end of it (since struct sock is really
just a
From: Kees Cook
Date: Fri, 16 Feb 2024 12:44:24 -0800
> While testing for places where zero-sized destinations were still
> showing up in the kernel, sock_copy() was found, which is using very
> specific memcpy() offsets for both avoiding a portion of struct sock,
> and copying beyond the end of
On Fri, Feb 16, 2024 at 12:39:41PM -0800, Kees Cook wrote:
> When a memcpy() would exceed the length of an entire structure, no
> detailed WARN would be emitted, making debugging a bit more challenging.
> Similarly, other buffer overflow reports would have no size information
> reported.
>
>
On Fri, Feb 16, 2024 at 01:27:56PM -0600, Gustavo A. R. Silva wrote:
> Fix boot crash on Raspberry Pi by moving the update to `event->datalen`
> before data is copied into flexible-array member `data` via `memcpy()`.
>
> Flexible-array member `data` was annotated with `__counted_by(datalen)`
> in
While testing for places where zero-sized destinations were still
showing up in the kernel, sock_copy() was found, which is using very
specific memcpy() offsets for both avoiding a portion of struct sock,
and copying beyond the end of it (since struct sock is really just a
common header before the
When a memcpy() would exceed the length of an entire structure, no
detailed WARN would be emitted, making debugging a bit more challenging.
Similarly, other buffer overflow reports would have no size information
reported.
Always warn for memcpy() overflows, but distinguish between the two
cases
Le 16/02/2024 à 20:28, Kees Cook a écrit :
> On Fri, Feb 16, 2024 at 09:14:27AM +0100, Christophe Leroy wrote:
>> set_memory_ro(), set_memory_nx(), set_memory_x() and other helpers
>> can fail and return an error. In that case the memory might not be
>> protected as expected and the module
On Fri, Feb 16, 2024 at 09:14:27AM +0100, Christophe Leroy wrote:
> set_memory_ro(), set_memory_nx(), set_memory_x() and other helpers
> can fail and return an error. In that case the memory might not be
> protected as expected and the module loading has to be aborted to
> avoid security issues.
>
Fix boot crash on Raspberry Pi by moving the update to `event->datalen`
before data is copied into flexible-array member `data` via `memcpy()`.
Flexible-array member `data` was annotated with `__counted_by(datalen)`
in commit 62d19b358088 ("wifi: brcmfmac: fweh: Add __counted_by for
struct
On Fri, Feb 16, 2024 at 09:14:27AM +0100, Christophe Leroy wrote:
> set_memory_ro(), set_memory_nx(), set_memory_x() and other helpers
> can fail and return an error. In that case the memory might not be
> protected as expected and the module loading has to be aborted to
> avoid security issues.
>
On Sun, Feb 11, 2024 at 07:22:50PM +0100, Erick Archer wrote:
> Link: https://github.com/KSPP/linux/issues/162 [1]
> Link:
> https://www.kernel.org/doc/html/next/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments
> [2]
> Signed-off-by: Erick Archer
> ---
>
On Wed, Feb 14, 2024 at 08:18:01PM +0100, Oleg Nesterov wrote:
> On 02/14, Tycho Andersen wrote:
> >
> > On Wed, Feb 14, 2024 at 06:55:55PM +0100, Oleg Nesterov wrote:
> > >
> > > We want to check the "flags" argument at the start, we do not want to
> > > delay the "case 0:" check until we have
> Add rules for finding places where str_plural() can be used.
…
> +++ b/scripts/coccinelle/api/string_choices.cocci
> @@ -0,0 +1,41 @@
…
> +/// Find places to use string_choices.h's various helpers.
> +//
> +// Confidence: Medium
> +// Options: --no-includes --include-headers
> +virtual patch
>
On 16.02.2024 09:14, Christophe Leroy wrote:
> set_memory_ro(), set_memory_nx(), set_memory_x() and other helpers
> can fail and return an error. In that case the memory might not be
> protected as expected and the module loading has to be aborted to
> avoid security issues.
>
> Check return value
set_memory_ro(), set_memory_nx(), set_memory_x() and other helpers
can fail and return an error. In that case the memory might not be
protected as expected and the module loading has to be aborted to
avoid security issues.
Check return value of all calls to set_memory_XX() and handle
error if
32 matches
Mail list logo
