On 20/02/2025 3:46, Jakub Kicinski wrote:
On Wed, 19 Feb 2025 14:14:35 +0200 Tariq Toukan wrote:
On 18/02/2025 23:13, Jakub Kicinski wrote:
On Tue, 18 Feb 2025 17:53:14 +0200 Tariq Toukan wrote:
Maybe it wasn't clear enough.
We prefer the original patch, and provided the Reviewed-by tag for
On 20. Feb 2025, at 03:57, Kees Cook wrote:
> On Wed, Feb 19, 2025 at 11:47:31PM +0100, Thorsten Blum wrote:
>> strncpy() is deprecated for NUL-terminated destination buffers. Use
>> strscpy_pad() instead and remove the manual NUL-termination.
>
> When doing these conversions, please describe two
In most code paths variable move_kern_type_id remains uninitialized upon
return. By moving it to the goto, it is initialized in these code paths.
As well as others. Caught by Coverity.
Closes:
https://scan5.scan.coverity.com/#/project-view/63874/10063?selectedIssue=1595567
Fixes: e2b3c4ff5d183d (
On Wed, Feb 19, 2025 at 11:47:31PM +0100, Thorsten Blum wrote:
> strncpy() is deprecated for NUL-terminated destination buffers. Use
> strscpy_pad() instead and remove the manual NUL-termination.
When doing these conversions, please describe two aspects of
conversions:
- Why is it safe to be NUL
On Thu, Feb 13, 2025 at 03:10:36PM +0100, Thorsten Blum wrote:
> strncpy() is deprecated for NUL-terminated destination buffers. Use
> strscpy() instead and remove the manual NUL-termination.
>
> Compile-tested only.
>
> Link: https://github.com/KSPP/linux/issues/90
> Cc: linux-hardening@vger.ker
On Wed, 19 Feb 2025 14:14:35 +0200 Tariq Toukan wrote:
> On 18/02/2025 23:13, Jakub Kicinski wrote:
> > On Tue, 18 Feb 2025 17:53:14 +0200 Tariq Toukan wrote:
> >> Maybe it wasn't clear enough.
> >> We prefer the original patch, and provided the Reviewed-by tag for it.
> >
> > Can you explain
strncpy() is deprecated for NUL-terminated destination buffers. Use
strscpy_pad() instead and remove the manual NUL-termination.
Compile-tested only.
Link: https://github.com/KSPP/linux/issues/90
Cc: linux-hardening@vger.kernel.org
Signed-off-by: Thorsten Blum
---
net/rds/stats.c | 3 +--
1 fil
On 2/19/25 07:13, Valentin Schneider wrote:
>> Maybe I missed part of the discussion though. Is VMEMMAP your only
>> concern? I would have guessed that the more generic vmalloc()
>> functionality would be harder to pin down.
> Urgh, that'll teach me to send emails that late - I did indeed mean the
On 2/19/25 09:08, Joel Fernandes wrote:
>> Pretty much so yeah. That is, *if* there such a vmalloc'd address access in
>> early entry code - testing says it's not the case, but I haven't found a
>> way to instrumentally verify this.
> Ok, thanks for confirming. Maybe there is an address sanitizer w
From: Chuck Lever
On Tue, 04 Feb 2025 13:33:36 +1030, Gustavo A. R. Silva wrote:
> -Wflex-array-member-not-at-end was introduced in GCC-14, and we are
> getting ready to enable it, globally.
>
> So, in order to avoid ending up with a flexible-array member in the
> middle of other structs, we use
On Wed, Feb 19, 2025 at 12:49 PM Chuck Lever wrote:
>
> On 2/19/25 12:46 PM, Anna Schumaker wrote:
> > Hi Chuck,
> >
> > On Tue, Feb 18, 2025 at 1:10 PM Chuck Lever wrote:
> >>
> >> On 2/10/25 2:48 PM, Chuck Lever wrote:
> >>> On 2/3/25 10:03 PM, Gustavo A. R. Silva wrote:
> -Wflex-array-mem
On 2/19/25 12:46 PM, Anna Schumaker wrote:
> Hi Chuck,
>
> On Tue, Feb 18, 2025 at 1:10 PM Chuck Lever wrote:
>>
>> On 2/10/25 2:48 PM, Chuck Lever wrote:
>>> On 2/3/25 10:03 PM, Gustavo A. R. Silva wrote:
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are
getting ready
Hi Chuck,
On Tue, Feb 18, 2025 at 1:10 PM Chuck Lever wrote:
>
> On 2/10/25 2:48 PM, Chuck Lever wrote:
> > On 2/3/25 10:03 PM, Gustavo A. R. Silva wrote:
> >> -Wflex-array-member-not-at-end was introduced in GCC-14, and we are
> >> getting ready to enable it, globally.
> >>
> >> So, in order to
On Wed, Feb 19, 2025 at 04:32:56PM +0200, Gal Pressman wrote:
> Remove the hidden assumption that options are allocated at the end of
> the struct, and teach the compiler about them using a flexible array.
>
> With this, we can revert the unsafe_memcpy() call we have in
> tun_dst_unclone() [1], an
On Wed, Feb 19, 2025 at 04:32:55PM +0200, Gal Pressman wrote:
> Tunnel options should not be accessed directly, use the ip_tunnel_info()
> accessor instead.
>
> Signed-off-by: Gal Pressman
Reviewed-by: Kees Cook
--
Kees Cook
On Tue, Feb 18, 2025 at 6:18 PM Pedro Falcato wrote:
>
> On Thu, Feb 13, 2025 at 8:47 PM Kees Cook wrote:
> >
> > On Thu, Feb 13, 2025 at 07:59:48PM +, Pedro Falcato wrote:
> > > On Wed, Feb 12, 2025 at 2:02 PM Lorenzo Stoakes
> > > wrote:
> > > >
> > > > (sorry I really am struggling to rep
On 2/19/2025 11:18 AM, Valentin Schneider wrote:
> On 19/02/25 10:05, Joel Fernandes wrote:
>> On Fri, Jan 17, 2025 at 05:53:33PM +0100, Valentin Schneider wrote:
>>> On 17/01/25 16:52, Jann Horn wrote:
On Fri, Jan 17, 2025 at 4:25 PM Valentin Schneider
wrote:
> On 14/01/25 19:16
On 19/02/25 10:05, Joel Fernandes wrote:
> On Fri, Jan 17, 2025 at 05:53:33PM +0100, Valentin Schneider wrote:
>> On 17/01/25 16:52, Jann Horn wrote:
>> > On Fri, Jan 17, 2025 at 4:25 PM Valentin Schneider
>> > wrote:
>> >> On 14/01/25 19:16, Jann Horn wrote:
>> >> > On Tue, Jan 14, 2025 at 6:51
On 18/02/25 16:39, Dave Hansen wrote:
> On 2/18/25 14:40, Valentin Schneider wrote:
>>> In practice, it's mostly limited like that.
>>>
>>> Architecturally, there are no promises from the CPU. It is within its
>>> rights to cache anything from the page tables at any time. If it's in
>>> the CR3 tre
On Fri, Jan 17, 2025 at 05:53:33PM +0100, Valentin Schneider wrote:
> On 17/01/25 16:52, Jann Horn wrote:
> > On Fri, Jan 17, 2025 at 4:25 PM Valentin Schneider
> > wrote:
> >> On 14/01/25 19:16, Jann Horn wrote:
> >> > On Tue, Jan 14, 2025 at 6:51 PM Valentin Schneider
> >> > wrote:
> >> >> vu
Tunnel options should not be accessed directly, use the ip_tunnel_info()
accessor instead.
Signed-off-by: Gal Pressman
---
include/net/ip_tunnels.h | 2 +-
net/sched/act_tunnel_key.c | 8
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/net/ip_tunnels.h b/include
Remove the hidden assumption that options are allocated at the end of
the struct, and teach the compiler about them using a flexible array.
First patch is converting hard-coded 'info + 1' to use ip_tunnel_info()
helper.
Second patch adds the 'options' flexible array and changes the helper to
use i
Remove the hidden assumption that options are allocated at the end of
the struct, and teach the compiler about them using a flexible array.
With this, we can revert the unsafe_memcpy() call we have in
tun_dst_unclone() [1], and resolve the false field-spanning write
warning caused by the memcpy()
On 18/02/25 20:18, Pedro Falcato wrote:
> On Thu, Feb 13, 2025 at 8:47 PM Kees Cook wrote:
>>
>> On Thu, Feb 13, 2025 at 07:59:48PM +, Pedro Falcato wrote:
>>> On Wed, Feb 12, 2025 at 2:02 PM Lorenzo Stoakes
>>> wrote:
(sorry I really am struggling to reply to mail as lore still
On 18/02/2025 23:13, Jakub Kicinski wrote:
On Tue, 18 Feb 2025 17:53:14 +0200 Tariq Toukan wrote:
Maybe it wasn't clear enough.
We prefer the original patch, and provided the Reviewed-by tag for it.
Can you explain what do you mean by "cleaner"?
I like the alternative much more.
Cleaner i
25 matches
Mail list logo
