On December 16, 2024 6:41:56 PM PST, Kuniyuki Iwashima
wrote:
>From: Kees Cook
>Date: Mon, 16 Dec 2024 18:04:45 -0800
>> Instead of a heap allocation use a stack allocated struct sockaddr, as
>> dev_set_mac_address_user() is the consumer (which uses a classic
>> struct sockaddr).
>
>I remembe
On December 16, 2024 8:12:07 PM PST, Matthew Wilcox wrote:
>On Mon, Dec 16, 2024 at 02:45:15PM -0800, Kees Cook wrote:
>> Since we have already allocated "len + 1" space for event->name, make sure
>> that name->name cannot ever accidentally cause a copy overflow by calling
>> strscpy() instead
On Mon, Dec 16, 2024 at 02:45:15PM -0800, Kees Cook wrote:
> Since we have already allocated "len + 1" space for event->name, make sure
> that name->name cannot ever accidentally cause a copy overflow by calling
> strscpy() instead of the unbounded strcpy() routine. This assists in
> the ongoing ef
On Mon, Dec 16, 2024 at 05:26:19PM -0800, Kees Cook wrote:
> -extern bool inet_addr_is_any(struct sockaddr *addr);
> +extern bool inet_addr_is_any(struct sockaddr_storage *addr);
You might want to drop the pointless extern here.
Otherwise this looks great:
Reviewed-by: Christoph Hellwig
This switches to using a manually constructed form of struct tagging
to avoid issues with C++ being unable to parse tagged structs within
anonymous unions, even under 'extern "C"':
../linux/include/uapi/linux/pkt_cls.h:25124: error: ‘struct
tc_u32_seltc_u32_sel_hdr,’ invalid; an anonymous u
From: Kees Cook
Date: Mon, 16 Dec 2024 18:04:45 -0800
> Instead of a heap allocation use a stack allocated struct sockaddr, as
> dev_set_mac_address_user() is the consumer (which uses a classic
> struct sockaddr).
I remember Eric's feedback was to keep using heap instead of stack
because rtnl_new
Instead of a heap allocation use a stack allocated struct sockaddr, as
dev_set_mac_address_user() is the consumer (which uses a classic
struct sockaddr). Cap the copy to the minimum address size between
the incoming address and the traditional sa_data field itself.
Putting "sa" on the stack means
On Tue, Nov 05, 2024 at 11:59:49AM +0100, Eric Dumazet wrote:
>
> On 11/4/24 11:25 PM, Kees Cook wrote:
> > Instead of a heap allocation use a stack allocated sockaddr_storage to
> > support arbitrary length addr_len value (but bounds check it against the
> > maximum address length).
> >
> > Sign
All the callers of inet_addr_is_any() have a sockaddr_storage-backed
sockaddr. Avoid casts and switch prototype to the actual object being
used, as part of the work to move away from internal use of struct
sockaddr.
Signed-off-by: Kees Cook
---
Cc: Christoph Hellwig
Cc: Sagi Grimberg
Cc: Chaita
As part of trying to clean up struct sock_addr, add comments about the
sockaddr arguments of dev_[gs]et_mac_address() being actual classic "max
14 bytes in sa_data" sockaddr instances and not struct sockaddr_storage.
Signed-off-by: Kees Cook
---
Cc: "David S. Miller"
Cc: Eric Dumazet
Cc: Jakub
Since we have already allocated "len + 1" space for event->name, make sure
that name->name cannot ever accidentally cause a copy overflow by calling
strscpy() instead of the unbounded strcpy() routine. This assists in
the ongoing efforts to remove the unsafe strcpy() API[1] from the kernel.
Link:
Hi Liam
On Mon, Dec 16, 2024 at 10:56 AM Liam R. Howlett
wrote:
>
> * Jeff Xu [241216 13:35]:
>
> ...
>
> > >
> > > I like the idea and I think the opt-out solution should work for CRIU.
> > > CRIU will be able to call this prctl and re-execute itself.
> > >
> > Great! Let's iterate on the opt-o
Hi Andrei
On Thu, Dec 12, 2024 at 10:33 PM Andrei Vagin wrote:
>
> On Wed, Dec 11, 2024 at 2:47 PM Jeff Xu wrote:
> >
> > Hi Andrei
> >
> > Thanks for your email.
> > I was hoping to get some feedback from CRIU devs, and happy to see you
> > reaching out..
> >
> ...
> > I have been thinking of o
Hello, Matthew!
> On Wed, Dec 04, 2024 at 09:51:07AM +0100, Uladzislau Rezki wrote:
> > I think, when i have more free cycles, i will check it from performance
> > point of view. Because i do not know how much a maple tree is efficient
> > when it comes to lookups, insert and removing.
>
> Maple
A kobject is meant to manage the lifecycle of some resource.
However the module sysfs code only creates a kobject to get a
"notes" subdirectory in sysfs.
This can be achieved easier and cheaper by using a sysfs group.
Switch the notes attribute code to such a group, similar to how the
section alloc
The existing allocation logic manually stuffs two allocations into one.
This is hard to understand and of limited value, given that all the
section names are allocated on their own anyways.
Une one allocation per datastructure.
Signed-off-by: Thomas Weißschuh
---
kernel/module/sysfs.c | 18 +
The member is only used to iterate over all attributes in
free_sect_attrs(). However the attribute group can already be used for
that. Use the group and drop 'nsections'.
Signed-off-by: Thomas Weißschuh
---
kernel/module/sysfs.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
dif
The sysfs core is switching to 'const struct bin_attribute's.
Prepare for that.
Signed-off-by: Thomas Weißschuh
---
kernel/module/sysfs.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/kernel/module/sysfs.c b/kernel/module/sysfs.c
index
4f3797
The sysfs core is switching to 'const struct bin_attribute's.
Prepare for that.
Signed-off-by: Thomas Weißschuh
---
Thomas Weißschuh (4):
module: sysfs: Drop member 'nsections'
module: sysfs: Simplify section attribute allocation
module: sysfs: Add notes attributes through attri
* Jeff Xu [241216 13:35]:
...
> >
> > I like the idea and I think the opt-out solution should work for CRIU.
> > CRIU will be able to call this prctl and re-execute itself.
> >
> Great! Let's iterate on the opt-out solution then.
>
This patch set has been NACK'ed.
Please rework your solution
On Mon, Dec 16, 2024 at 07:21:11AM +, Korenblit, Miriam Rachel wrote:
> The patch was already applied and marked in Patchwork as such.
Hi! Oh, I guess it hasn't made its way to -next yet? Thanks for
checking!
-Kees
--
Kees Cook
On 12/15/24 20:25, Jonathan Cameron wrote:
On Tue, 10 Dec 2024 12:24:03 +0800
Yasin Lee wrote:
Configuration information is now prioritized from the firmware file.
If the firmware file is missing or fails to parse, the driver falls
back to using the default configuration list for writing the s
Configuration information is now prioritized from the firmware file.
If the firmware file is missing or fails to parse, the driver falls
back to using the default configuration list for writing the settings.
Signed-off-by: Yasin Lee
---
Changes in v2:
- Removed unnecessary null checks for firmwar
23 matches
Mail list logo
