linux-kernel - Re: [PATCH] Fix KMSAN infoleak, initialize unused data in pskb_expand

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAGiJo8QU81+oLG+s-c2dUsQ_+4csaKEv6xmt=yJrA2gZ22ZWXw@mail.gmail.com>
Date: Fri, 4 Oct 2024 21:59:23 -0700
From: Daniel Yang <danielyangkang@...il.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: Daniel Borkmann <daniel@...earbox.net>, "David S. Miller" <davem@...emloft.net>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org, 
	linux-kernel@...r.kernel.org, 
	syzbot+346474e3bf0b26bd3090@...kaller.appspotmail.com
Subject: Re: [PATCH] Fix KMSAN infoleak, initialize unused data in pskb_expand_head

On Thu, Oct 3, 2024 at 12:56 AM Eric Dumazet <edumazet@...gle.com> wrote:
>
> On Thu, Oct 3, 2024 at 6:42 AM Daniel Yang <danielyangkang@...il.com> wrote:
> >
> > I took a look at https://www.spinics.net/lists/netdev/msg982652.html
> > and am a little confused since the patch adds a check instead of
> > initializing the memory segment.
> > Is the general assumption that any packet with uninitialized memory is
> > ill formed and we need to drop? Also is there any documentation for
> > internal macros/function calls for BPF because I was trying to look
> > and couldn't find any.
>
> Callers wanting allocated memory to be cleared use __GFP_ZERO
> If we were forcing  __GFP_ZERO all the time, network performance would
> be reduced by 30% at least.
>
> You are working around the real bug, just to silence a useful warning.
>
> As I explained earlier, the real bug is that some layers think the
> ethernet header (14 bytes) is present in the packet.
>
> Providing 14 zero bytes (instead of random bytes) would still be a bug.
>
> The real fix is to drop malicious packets when they are too small, like a NIC.

Interesting. Thank you for the clarification.