On Tue, Sep 19, 2023 at 12:22 PM Azeem Shaikh wrote:
>
> strlcpy() reads the entire source buffer first and returns the size of
> the source string, not the destination string, which can be accidentally
> misused [1].
>
> The copy_to_user() call uses @len returned from strlcpy() directly
> without
On Thu, Sep 14, 2023 at 05:20:41PM -0700, Kees Cook wrote:
> Because they're ambiguous and then the compiler can't do appropriate
> bounds checking, compile-time diagnostics, etc. Maybe it's actually zero
> sized, maybe it's not. Nothing stops them from being in the middle of
> the structure so if
strlcpy() reads the entire source buffer first and returns the size of
the source string, not the destination string, which can be accidentally
misused [1].
The copy_to_user() call uses @len returned from strlcpy() directly
without checking its value. This could potentially lead to read
overflow.
On 9/12/23 18:16, Kees Cook wrote:
On Tue, Sep 12, 2023 at 07:59:30AM -0400, Przemek Kitszel wrote:
Add DEFINE_FLEX() macro, that helps on-stack allocation of structures
with trailing flex array member.
Expose __struct_size() macro which reads size of data allocated
by DEFINE_FLEX().
Accompany
Justin Stitt writes:
> `strncpy` is deprecated for use on NUL-terminated destination strings [1].
>
> A suitable replacement is `memcpy` as we've already precisely calculated
> the number of bytes to copy while `buf` has been explicitly
> zero-initialized:
> | char buf[8] = { 0 };
>
> Link:
>
On Sun, 17 Sep 2023 15:21:36 -0600, Gustavo A. R. Silva wrote:
> If, for any reason, the open-coded arithmetic causes a wraparound,
> the protection that `struct_size()` provides against potential integer
> overflows is defeated. Fix this by hardening calls to `struct_size()`
> with `size_add()`,
On Sun, Sep 17, 2023 at 03:21:36PM -0600, Gustavo A. R. Silva wrote:
> If, for any reason, the open-coded arithmetic causes a wraparound,
The thing is that it doesn't.
> the protection that `struct_size()` provides against potential integer
> overflows is defeated. Fix this by hardening calls to
On 2023-09-19 05:07:55+, Justin Stitt wrote:
> `strncpy` is deprecated for use on NUL-terminated destination strings [1].
>
> A trailing zero is already handled by the kcalloc
> | *str = kcalloc(element->string.length + 1, sizeof(u8), GFP_KERNEL);
> ... which makes memcpy() a suitable repl
