On Fri, 11 Jul 2025 08:05:38 +0200
Martin Uecker wrote:
> Am Donnerstag, dem 10.07.2025 um 14:58 -0700 schrieb Linus Torvalds:
> > On Thu, 10 Jul 2025 at 14:31, Alejandro Colomar wrote:
> > >
> > > These macros are essentially the same as the 2-argument version of
> > > strscpy(), but with a
On Fri, 11 Jul 2025 01:23:49 +0200
Alejandro Colomar wrote:
> Hi Linus,
>
> [I'll reply to both of your emails at once]
>
> On Thu, Jul 10, 2025 at 02:58:24PM -0700, Linus Torvalds wrote:
> > You took my suggestion, and then you messed it up.
> >
> > Your version of sprintf_array() is broken.
On Mon, 19 May 2025 10:59:30 -0400
"Theodore Ts'o" wrote:
> On Mon, May 19, 2025 at 06:52:13AM -0700, Kees Cook wrote:
> > > --- a/fs/ext4/inline.c
> > > +++ b/fs/ext4/inline.c
> > > @@ -1314,7 +1314,7 @@ int ext4_inlinedir_to_tree(struct file *dir_file,
> > > if (pos == 0) {
> > >
On Sun, 20 Apr 2025 21:33:19 -0700
Linus Torvalds wrote:
> On Sun, 20 Apr 2025 at 18:52, Kees Cook wrote:
> >
> > Can you please revert this mess and use what has already been planned
> > for this warning? It is, once again, really frustrating when you update
> > to unreleased compiler versions.
On Wed, 2 Apr 2025 17:08:51 -0700
Peter Collingbourne wrote:
> On Wed, Apr 2, 2025 at 1:10 PM Catalin Marinas
> wrote:
..
> > Reading across tag granule (but not across page boundary) and causing a
> > tag check fault would result in padding but we can live with this and
> > only architectures
On Fri, 21 Mar 2025 13:40:57 -0700
Kees Cook wrote:
> As a prerequisite to being able to optionally take the address of any
> lvalues used in a call to kfree(), replace casts to the kfree() argument
> with unions to include an actual pointer.
Having different names for the argument to kfree() an
On Wed, 12 Mar 2025 13:05:36 -0700
Kees Cook wrote:
> When a character array without a terminating NUL character has a static
> initializer, GCC 15's -Wunterminated-string-initialization will only
> warn if the array lacks the "nonstring" attribute[1]. There is no reason
> for the command lookup
On Mon, 17 Feb 2025 14:13:21 +0100
Peter Zijlstra wrote:
> On Mon, Feb 17, 2025 at 01:06:29PM +0000, David Laight wrote:
> > On Sat, 15 Feb 2025 22:07:29 +0100
> > Peter Zijlstra wrote:
> >
> > > On Fri, Feb 14, 2025 at 10:57:51AM +0100, Peter Zijlstra wrote:
On Sat, 15 Feb 2025 22:07:29 +0100
Peter Zijlstra wrote:
> On Fri, Feb 14, 2025 at 10:57:51AM +0100, Peter Zijlstra wrote:
> > On Thu, Feb 13, 2025 at 12:53:28PM -0800, Kees Cook wrote:
> >
> > > Right, the "if they can control a function pointer" is the part I'm
> > > focusing on. This attack
On Thu, 13 Feb 2025 12:34:55 -0800
Bart Van Assche wrote:
> On 2/13/25 11:53 AM, Thorsten Blum wrote:
> > diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
> > index 84d8de07b7ae..c7ebae24b09f 100644
> > --- a/drivers/scsi/hpsa.c
> > +++ b/drivers/scsi/hpsa.c
> > @@ -460,9 +460,8 @@ static s
On Wed, 12 Feb 2025 23:43:53 +0100
Thorsten Blum wrote:
> strncpy() is deprecated for NUL-terminated destination buffers [1].
>
> Replace memset() and strncpy() with strscpy_pad() to copy the version
> string and fill the remaining bytes in the destination buffer with NUL
> bytes. This avoids ze
On Fri, 07 Feb 2025 09:55:00 +0100
Rasmus Villemoes wrote:
> On Thu, Feb 06 2025, Kees Cook wrote:
>
> > In preparation for adding stricter type checking to the str/mem*()
> > helpers, provide a way to check that a variable is a character array
> > via __must_be_char_array().
> >
> > Signed-off
On Thu, 6 Feb 2025 10:11:29 -0800
Kees Cook wrote:
> In preparation for adding stricter type checking to the str/mem*()
> helpers, provide a way to check that a variable is a character array
> via __must_be_char_array().
>
...
> +#define __is_char_array(a) (__is_array(a) && sizeof((a)[0]) ==
...
> > +config HARDENED_USERCOPY_DEFAULT_ON
> > + bool "Harden memory copies by default"
> > + depends on HARDENED_USERCOPY
> > + default n
>
> This must be "default HARDENED_USERCOPY" or existing distro builds will
> break. All major distros enable this by default, and I don't want to
On Sat, 11 Jan 2025 23:40:41 +0900
Vincent Mailhol wrote:
> On Thu. 9 Jan 2025 at 16:52, Vincent Mailhol
> wrote:
...
> Actually, I did more investigation and it is working for some strange
> reasons. Whenever the argument of a function named strlen() is a
> compile time constant, the compiler
From: Kees Cook
> Sent: 14 December 2024 01:36
...
> In order to silence this false positive but keep deterministic
> compile-time warnings intact, hide the length variable from GCC with
> OPTIMIZE_HIDE_VAR() before calling the builtin memcpy.
...
> diff --git a/include/linux/fortify-string.h b/inc
From: Kees Cook
> Sent: 30 November 2024 04:49
>
> Instead of adding a new use of the ambiguous strncpy(), we'd want to
> use memtostr_pad() which enforces being able to check at compile time
> that sizes are sensible, but this requires being able to see string
> buffer lengths. Instead of trying t
From: Gustavo A. R. Silva
> Sent: 16 October 2024 01:27
>
> We are currently working on enabling the -Wflex-array-member-not-at-end
> compiler option. This option has helped us detect several objects of
> the type `struct sockaddr` that appear in the middle of composite
> structures like `struct r
From: Bartosz Golaszewski
> Sent: 22 October 2024 08:30
>
> On Tue, Oct 22, 2024 at 9:15 AM Jiri Slaby wrote:
> >
> > On 21. 10. 24, 12:04, Bartosz Golaszewski wrote:
> > > From: Bartosz Golaszewski
> > >
> > > The output of ".%03u" with the unsigned int in range [0, 4294966295] may
> > > get tr
...
> > [1] Both the '+' and '*' have extra code to detect overflow and return
> > a 'big' value that will cause kmalloc() to return NULL.
> > I've not looked at the generated code but it is likely to be horrid
> > (especially the check for multiply overflowing).
> > In this case there are enou
From: Vincent Mailhol
> Sent: 10 September 2024 03:50
>
> If the offsetof() of a given flexible array member (fam) is smaller
> than the sizeof() of the containing struct, then the struct_size()
> macro reports a size which is too big.
>
> This occurs when the two conditions below are met:
>
>
From: Vincent Mailhol
> Sent: 09 September 2024 12:52
>
> If the offsetof() of a given flexible array member (fam) is smaller
> than the sizeof() of the containing struct, then the struct_size()
> macro reports a size which is too big.
>
> This occurs when the two conditions below are met:
>
>
From: Dan Carpenter
> Sent: 14 May 2024 09:45
>
> Snipped all the bits where you are clearly correct.
>
> On Mon, May 13, 2024 at 12:43:37PM -0700, Kees Cook wrote:
> > > drivers/usb/class/usbtmc.c:852 usbtmc_generic_read() warn: potential
> > > integer overflow from user
> 'max_transfer_size +
From: Kees Cook
> Sent: 16 May 2024 14:31
>
> On May 15, 2024 12:36:36 AM PDT, Peter Zijlstra wrote:
> >On Wed, May 08, 2024 at 04:47:25PM -0700, Linus Torvalds wrote:
> >> For example, the most common case of overflow we've ever had has very
> >> much been array indexing. Now, sometimes that has
...
> I think that would be a completely different area that might be worth
> looking at: instrumenting implicit casts for "drops bits". I'm afraid
> that it's just *so* common than we might not be able to do that
> sanely.
Things like:
buf[0] = val;
buf[1] = val >>= 8;
buf
...
> Going the other way is similar:
>
> all_bits = low_bits + ((u64) high_bits << 16) << 16);
>
> and again, the compiler will recognize this idiom and do the right
> thing (and if 'all_bits' is only 32-bit, the compiler will optimize
> the high bit noise away).
On a 32bit system the c
From: Kees Cook
> Sent: 08 May 2024 00:28
>
> Over the last decade or so, our work hardening against weaknesses
> in various kernel APIs and eliminating the ambiguities in C language
> semantics have traditionally been somewhat off in one corner or another
> of the Linux codebase. This topic is go
From: Kees Cook
> Sent: 02 May 2024 16:11
>
> On Thu, May 02, 2024 at 06:03:04PM +0300, Andy Shevchenko wrote:
> > On Thu, May 2, 2024 at 5:59 PM Andy Shevchenko
> > wrote:
> > > On Thu, May 2, 2024 at 5:14 PM Hsin-Yu.Chen wrote:
> >
> > And on top of that, check what this code will do on the ar
From: Kees Cook
> Sent: 11 April 2024 16:32
>
> On Wed, Apr 10, 2024 at 01:45:21PM -0700, Justin Stitt wrote:
> > On Tue, Apr 9, 2024 at 9:22 AM Kees Cook wrote:
> > > >
> > > > - /* 1 larger than sb_fname, so this ensures a trailing NUL char */
> > > > - memset(label, 0, sizeof(label));
...
> Whereas we already provide an abort() function because iirc the
> compiler used to emit branches to that due to noreturn functions. If
> correct, there's previous convention for doing this - and abort() is
> still exists in the kernel and in userspace since it's part of ANSI
> C. This would b
From: Russell King
> Sent: 22 March 2024 00:09
>
> On Thu, Mar 21, 2024 at 11:43:41PM +0100, Ard Biesheuvel wrote:
> > Given that this particular issue would just disappear if the compiler
> > would just insert a BRK after the BL, I'd prefer to explore first
> > whether we can get this fixed on th
From: Russell King
> Sent: 21 March 2024 14:56
>
> On Thu, Mar 21, 2024 at 02:37:28PM +0000, David Laight wrote:
> > From: Russell King
> > > Sent: 21 March 2024 13:08
> > >
> > > On Thu, Mar 21, 2024 at 12:57:07PM +, David Laight wrote:
> >
From: Russell King
> Sent: 21 March 2024 13:08
>
> On Thu, Mar 21, 2024 at 12:57:07PM +0000, David Laight wrote:
> > From: Russell King
> > > Sent: 21 March 2024 12:23
> > ...
> > > > That might mean you can get the BL in the middle of a function
> >
From: Russell King
> Sent: 21 March 2024 12:23
...
> > That might mean you can get the BL in the middle of a function
> > but where the following instruction is for the 'no stack frame'
> > side of the branch.
> > That is very likely to break any stack offset calculations.
>
> No it can't. At any
From: Russell King
> Sent: 21 March 2024 11:24
>
> On Thu, Mar 21, 2024 at 10:22:30AM +0000, David Laight wrote:
> > How aggressively does the compiler optimise 'noreturn' functions?
>
> I've seen cases where the compiler emits a BL instruction as the ve
How aggressively does the compiler optimise 'noreturn' functions?
Consider:
void f(...)
{
...
if () {
...
noreturn(...);
}
}
Without the noreturn() call it is a leaf function.
So the compiler doesn't need to save 'lr' on stack
(or the save co
From: Russell King
> Sent: 06 March 2024 09:52
>
> On Tue, Mar 05, 2024 at 09:58:46AM -0800, Josh Poimboeuf wrote:
> > This is an off-by-one bug which is common in unwinders, due to the fact
> > that the address on the stack points to the return address rather than
> > the call address.
> >
> > So
From: Justin Stitt
> Sent: 21 February 2024 22:12
>
> I am going to quote Lee Jones who has been doing some snprintf ->
> scnprintf refactorings:
>
> "There is a general misunderstanding amongst engineers that
> {v}snprintf() returns the length of the data *actually* encoded into the
> destinatio
From: Pavel Machek
> Sent: 07 February 2024 17:52
> > > Using sizeof(dst) is the overwhelmingly common case for strscpy().
> > > Instead of requiring this everywhere, allow a 2-argument version to be
> > > used that will use the sizeof() internally.
> >
> > Yeah, this is definitely the case. I have
From: Pavel Machek
> Sent: 07 February 2024 17:52
>
> > > Using sizeof(dst) is the overwhelmingly common case for strscpy().
> > > Instead of requiring this everywhere, allow a 2-argument version to be
> > > used that will use the sizeof() internally.
> >
> > Yeah, this is definitely the case. I h
From: Kees Cook
> Sent: 07 February 2024 09:19
>
> On Wed, Feb 07, 2024 at 12:51:51AM +, Justin Stitt wrote:
> > Hi,
> >
> > On Tue, Feb 06, 2024 at 06:22:18AM -0800, Kees Cook wrote:
> > > Similar to strscpy(), update strscpy_pad()'s 3rd argument to be
> > > optional when the destination is a
From: Kees Cook
> Sent: 29 January 2024 20:29
>
> Using sizeof(dst) is the overwhelmingly common case for strscpy().
> Instead of requiring this everywhere, allow a 2-argument version to be
> used that will use the sizeof() internally.
You may want to (try to) add a check that the first argument
...
> > 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 single overflow check at the end.
> >
> > Forget the check, and the length just contains a trailing '\0'
> >
From: Linus Torvalds
> Sent: 26 January 2024 22:36
>
> On Fri, 26 Jan 2024 at 14:24, Kees Cook wrote:
> >
> > I think xe has some other weird problems too. This may be related (under
> > allocating):
> >
> > ../drivers/gpu/drm/xe/xe_vm.c: In function 'xe_vma_create':
> > ../drivers/gpu/drm/xe/xe_
From: Lee Jones
> Sent: 25 January 2024 10:36
> On Thu, 25 Jan 2024, Rasmus Villemoes wrote:
>
> > On 25/01/2024 09.39, Lee Jones wrote:
> > > 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
> > >
From: Kees Cook
> Sent: 06 December 2023 20:59
>
> The return value from nla_len() is never expected to be negative, and can
> never be more than struct nlattr::nla_len (a u16). Adjust the prototype
> on the function. This will let GCC's value range optimization passes
> know that the return can n
46 matches
Mail list logo
