Quoting Erick Archer (2024-01-21 06:29:46)
> As noted in the "Deprecated Interfaces, Language Features, Attributes,
> and Conventions" documentation [1], size calculations (especially
> multiplication) should not be performed in memory allocator (or similar)
> function arguments due to the risk of
On February 21, 2024 4:41:52 PM PST, Justin Stitt
wrote:
>strncpy() is deprecated for use on NUL-terminated destination strings
>[1] and as such we should prefer more robust and less ambiguous string
>interfaces.
>
>We expect ae->value_string to be NUL-terminated because there's a
>comment
n Stitt
> ---
> Changes in v2:
> - Had a vim moment and deleted a character before sending the patch.
> - Replaced the character :)
> - Link to v1:
> https://lore.kernel.org/r/20240221-snprintf-checkpatch-v1-1-3ac5025b5...@google.com
> ---
> From a discussion here [1].
>
strncpy() is deprecated for use on NUL-terminated destination strings
[1] and as such we should prefer more robust and less ambiguous string
interfaces.
We expect ae->value_string to be NUL-terminated because there's a
comment that says as much; these attr strings are also used with other
string
On Wed, Feb 21, 2024 at 11:50:26PM +, Justin Stitt wrote:
> strncpy() is deprecated [1] and as such we should use different apis to
> copy string data.
>
> We can see that ct is NUL-initialized with fc_ct_hdr_fill:
> | ct = fc_ct_hdr_fill(fp, op, sizeof(struct fc_ns_rspn) + len,
> ...
>
strncpy() is deprecated [1] and as such we should use different apis to
copy string data.
We can see that ct is NUL-initialized with fc_ct_hdr_fill:
| ct = fc_ct_hdr_fill(fp, op, sizeof(struct fc_ns_rspn) + len,
...
In fc_ct_hdr_fill():
| memset(ct, 0, ct_plen);
We also calculate
y: Justin Stitt
Yes please! :)
Reviewed-by: Kees Cook
-Kees
> ---
> Changes in v2:
> - Had a vim moment and deleted a character before sending the patch.
> - Replaced the character :)
> - Link to v1:
> https://lore.kernel.org/r/20240221-snprintf-checkpatch-v1-1-3ac5025b5...@g
ub.com/KSPP/linux/issues/90\n; . $herecurr);
> }
>
> +# snprintf uses that should likely be {v}scnprintf
> + if ($line =~ /\snprintf\s*\(\s*/) {
> + WARN("SNPRINTF",
> +"Prefer scnpri
to v1:
https://lore.kernel.org/r/20240221-snprintf-checkpatch-v1-1-3ac5025b5...@google.com
---
>From a discussion here [1].
[1]:
https://lore.kernel.org/all/0f9c95f9-2c14-eee6-7faf-635880edc...@linux-m68k.org/
---
scripts/checkpatch.pl | 6 ++
1 file changed, 6 insertions(+)
diff --git a/scripts
N("PREFER_ETHTOOL_PUTS",
---
base-commit: b401b621758e46812da61fa58a67c3fd8d91de0d
change-id: 20240221-snprintf-checkpatch-a864ed67ebd0
Best regards,
--
Justin Stitt
Hello!
I think this is a good idea.
Some minor implementation remarks below.
On Mon, Feb 19, 2024 at 08:18:04PM +0100, Mickaël Salaün wrote:
> Because sandboxing can be used as an opportunistic security measure,
> user space may not log unsupported features. Let the system
> administrator know
On Sat, Feb 17, 2024 at 03:29:13PM +0100, Erick Archer wrote:
> When a struct containing a flexible array is included in another struct,
> and there is a member after the struct-with-flex-array, there is a
> possibility of memory overlap. These cases must be audited [1]. See:
>
> struct inner {
>
On 2/19/24 7:39 AM, Christophe Leroy wrote:
Le 19/02/2024 à 02:40, Hengqi Chen a écrit :
[Vous ne recevez pas souvent de courriers de hengqi.c...@gmail.com. Découvrez
pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]
Hello Christophe,
On Sun, Feb 18, 2024 at
Hi,
Thanks for looking at this.
On 2/21/24 06:44, Jason A. Donenfeld wrote:
Hi,
On Wed, Feb 21, 2024 at 7:33 AM Kees Cook wrote:
+#ifdef CONFIG_RANDOMIZE_KSTACK_OFFSET
+DEFINE_PER_CPU(u32, kstackrng);
+static u32 xorshift32(u32 state)
+{
+ /*
+ * From top of page 4 of Marsaglia,
Hi,
Thanks for looking at this!
On 2/21/24 00:33, Kees Cook wrote:
On Tue, Feb 20, 2024 at 08:02:58PM -0600, Jeremy Linton wrote:
The existing arm64 stack randomization uses the kernel rng to acquire
5 bits of address space randomization. This is problematic because it
creates non determinism
5.15-stable review patch. If anyone has any objections, please let me know.
--
From: Kees Cook
commit d219d2a9a92e39aa92799efe8f2aa21259b6dd82 upstream.
When the check_[op]_overflow() helpers were introduced, all arguments
were required to be the same type to make the
Hi,
On Wed, Feb 21, 2024 at 7:33 AM Kees Cook wrote:
> > +#ifdef CONFIG_RANDOMIZE_KSTACK_OFFSET
> > +DEFINE_PER_CPU(u32, kstackrng);
> > +static u32 xorshift32(u32 state)
> > +{
> > + /*
> > + * From top of page 4 of Marsaglia, "Xorshift RNGs"
> > + * This algorithm is intended to
On Wed, Feb 21, 2024 at 11:29:38AM +, Russell King (Oracle) wrote:
> On Tue, Feb 20, 2024 at 10:39:15PM -0800, Kees Cook wrote:
> > On Mon, Jan 22, 2024 at 05:12:38PM -0800, Kees Cook wrote:
> > > Under PAN emulation when dumping backtraces from things like the
> > > LKDTM EXEC_USERSPACE
On Tue, Feb 20, 2024 at 10:39:15PM -0800, Kees Cook wrote:
> On Mon, Jan 22, 2024 at 05:12:38PM -0800, Kees Cook wrote:
> > Under PAN emulation when dumping backtraces from things like the
> > LKDTM EXEC_USERSPACE test[1], a double fault (which would hang a CPU)
> > would happen because of
On Wed, Feb 21, 2024 at 6:16 AM Kees Cook wrote:
>
> Mark the various refcount_t functions with __signed_wrap, as we depend
> on the wrapping behavior to detect the overflow and perform saturation.
> Silences warnings seen with the LKDTM REFCOUNT_* tests:
>
> UBSAN: signed-integer-overflow in
On Wed, Feb 21, 2024, at 03:02, Jeremy Linton wrote:
> The existing arm64 stack randomization uses the kernel rng to acquire
> 5 bits of address space randomization. This is problematic because it
> creates non determinism in the syscall path when the rng needs to be
> generated or reseeded. This
21 matches
Mail list logo
