On Tue, Dec 17, 2024 at 12:30:36PM -0800, Kees Cook wrote:
> On Tue, Dec 17, 2024 at 10:35:44AM -0500, Willem de Bruijn wrote:
> > Kees Cook wrote:
> > > 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
On Sun, Dec 15, 2024 at 03:39:11PM +0200, Moshe Shemesh wrote:
>
>
> On 12/12/2024 7:23 PM, Simon Horman wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > On Wed, Dec 11, 2024 at 03:42:16PM +0200, Tariq Toukan wrote:
> > > From: Moshe Shemesh
> > >
> > > Refactor
On Mon, Nov 25, 2024 at 08:20:21PM +, jef...@chromium.org wrote:
> Seal vdso, vvar, sigpage, uprobes and vsyscall.
>
> Those mappings are readonly or executable only, sealing can protect
> them from ever changing or unmapped during the life time of the process.
> For complete descriptions of m
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.
Reviewed-by: Christoph Hellwig
Reviewed-by: Simon Horman
Signed-off-by: Kees Cook
---
v2: drop "extern" in header (hch)
v1: https://lore.kernel.org/
On Tue, Dec 17, 2024 at 10:35:44AM -0500, Willem de Bruijn wrote:
> Kees Cook wrote:
> > 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 soc
On Tue, Dec 17, 2024 at 11:10:41AM -0800, Christopher Ferris wrote:
> I verified that this does fix the compilation problem on Android. Thanks
> for working on this.
Thanks! Yeah, let's use Alexander's solution instead of my proposed patch.
> > [0]
> > https://github.com/alobakin/linux/commit/2a0
On 17/12/24 13:10, Christopher Ferris wrote:
I verified that this does fix the compilation problem on Android. Thanks
for working on this.
Awesome! :)
Thanks for confirming.
-Gustavo
Christopher
On Tue, Dec 17, 2024 at 10:31 AM Gustavo A. R. Silva
wrote:
On 17/12/24 10:54, Alexand
On 17/12/24 10:54, Alexander Lobakin wrote:
From: Gustavo A. R. Silva
Date: Tue, 17 Dec 2024 10:25:29 -0600
On 17/12/24 10:04, Alexander Lobakin wrote:
From: Gustavo A. R. Silva
Date: Tue, 17 Dec 2024 09:58:28 -0600
On 17/12/24 08:55, Alexander Lobakin wrote:
From: Kees Cook
Date:
From: Gustavo A. R. Silva
Date: Tue, 17 Dec 2024 10:25:29 -0600
>
>
> On 17/12/24 10:04, Alexander Lobakin wrote:
>> From: Gustavo A. R. Silva
>> Date: Tue, 17 Dec 2024 09:58:28 -0600
>>
>>>
>>>
>>> On 17/12/24 08:55, Alexander Lobakin wrote:
From: Kees Cook
Date: Mon, 16 Dec 2024 1
On 17/12/24 10:04, Alexander Lobakin wrote:
From: Gustavo A. R. Silva
Date: Tue, 17 Dec 2024 09:58:28 -0600
On 17/12/24 08:55, Alexander Lobakin wrote:
From: Kees Cook
Date: Mon, 16 Dec 2024 18:59:55 -0800
This switches to using a manually constructed form of struct tagging
to avoid i
From: Gustavo A. R. Silva
Date: Tue, 17 Dec 2024 09:58:28 -0600
>
>
> On 17/12/24 08:55, Alexander Lobakin wrote:
>> From: Kees Cook
>> Date: Mon, 16 Dec 2024 18:59:55 -0800
>>
>>> This switches to using a manually constructed form of struct tagging
>>> to avoid issues with C++ being unable to
On Mon, Dec 16, 2024 at 05:26:19PM -0800, Kees Cook wrote:
> 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-
On 17/12/24 08:55, Alexander Lobakin wrote:
From: Kees Cook
Date: Mon, 16 Dec 2024 18:59:55 -0800
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
Kees Cook wrote:
> 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.
What is this assertion based on?
I see various non-Ethern
From: Kees Cook
Date: Mon, 16 Dec 2024 18:59:55 -0800
> 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: erro
On December 17, 2024 12:03:35 AM PST, Kuniyuki Iwashima
wrote:
>From: Kees Cook
>Date: Mon, 16 Dec 2024 23:53:46 -0800
>> 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
Hello,
On Tue, 3 Dec 2024 14:53:27 +0100
"Günther Noack" wrote:
> Hanno, you are the original author of this patch and you have done a
> more detailed analysis on the TIOCLINUX problems than me -- do you
> agree that this weakened check would still be sufficient to protect
> against the TIOCLINU
On Tue, Dec 17, 2024 at 09:47:23AM +0100, Hanno Böck wrote:
> Hello,
>
> On Tue, 3 Dec 2024 14:53:27 +0100
> "Günther Noack" wrote:
>
> > Hanno, you are the original author of this patch and you have done a
> > more detailed analysis on the TIOCLINUX problems than me -- do you
> > agree that thi
From: Kees Cook
Date: Mon, 16 Dec 2024 23:53:46 -0800
> 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
Le mar. 17 déc. 2024 à 03:05, Kees Cook a écrit :
>
> 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 tradit
20 matches
Mail list logo
