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
...
> 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;
...
> 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
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
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
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
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
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 very
> la
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
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.
> >
> >
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
>
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
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
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
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':
> >
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
24 matches
Mail list logo
