On Thu, 8 Feb 2024, Lee Jones wrote:
> On Thu, 08 Feb 2024, Geert Uytterhoeven wrote:
>
> >
> > Confused... The return value is not used at all?
>
> Future proofing.
>
Surely a better way to prevent potential future API abuse is by adding
checkpatch.pl rules. That way does not generate ch
On Fri, 23 Feb 2024, Justin Stitt wrote:
> @p1 is assigned to @setup_buffer and then we manually assign a NUL-byte
> at the first index. This renders the following strlen() call useless.
> Moreover, we don't need to reassign p1 to setup_buffer for any reason --
> neither do we need to manually s
On Fri, 23 Feb 2024, Justin Stitt wrote:
> Really, there's no bug with the current code.
If (hypothetically) you needed to reduce stack size, just copy the char
pointer instead of copying the chars onto the stack.
If (hypothetically) strncpy() was banned altogether (rather than merely
depre
On Mon, 29 Apr 2024, Kees Cook wrote:
> this isn't a case where we can show identical binary output, since this
> actively adds overflow checking via kcalloc() internals.
>
> ...
>
> it is a trivially correct change that uses a more robust API and more
> idiomatic allocation sizeof()s
If a
On Wed, 1 May 2024, James Bottomley wrote:
> > The code itself is fine unless you have a 32-bit system with a
> > malicious card, so yeah, near zero risk.
>
> Well, no actually zero: we assume plugged in hardware to operate
> correctly (had this argument in the driver hardening thread a while
