netdev - Re: [PATCH v1 net 1/5] sit: Pull header after checking skb->protocol in sit_tunnel

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANn89i+y8yqXZ3OHdzo5FxgwNs-j24-4wiNZKr8pSG+tvbYV9g@mail.gmail.com>
Date: Thu, 18 Apr 2024 08:56:45 +0200
From: Eric Dumazet <edumazet@...gle.com>
To: Kuniyuki Iwashima <kuniyu@...zon.com>
Cc: kuba@...nel.org, davem@...emloft.net, dsahern@...nel.org, 
	herbert@...dor.apana.org.au, kuni1840@...il.com, netdev@...r.kernel.org, 
	pabeni@...hat.com, steffen.klassert@...unet.com, syzkaller@...glegroups.com, 
	willemb@...gle.com
Subject: Re: [PATCH v1 net 1/5] sit: Pull header after checking skb->protocol
 in sit_tunnel_xmit().

On Thu, Apr 18, 2024 at 5:32 AM Kuniyuki Iwashima <kuniyu@...zon.com> wrote:
>
> From: Jakub Kicinski <kuba@...nel.org>
> Date: Wed, 17 Apr 2024 19:04:32 -0700
> > On Mon, 15 Apr 2024 15:20:37 -0700 Kuniyuki Iwashima wrote:
> > > syzkaller crafted a GSO packet of ETH_P_8021AD + ETH_P_NSH and sent it
> > > over sit0.
> > >
> > > After nsh_gso_segment(), skb->data - skb->head was 138, on the other
> > > hand, skb->network_header was 128.
> >
> > is data offset > skb->network_header valid at this stage?
> > Can't we drop these packets instead?
>
> I think that needs another fix on the NSH side.
>
> But even with that, we can still pass valid L2 skb to sit_tunnel_xmit()
> and friends, and then we should just drop it there without calling
> pskb_inet_may_pull() that should not be called for non-IP skb.

I dislike this patch series. I had this NSH bug for a while in my
queue, the bug is in NSH.

Also I added skb_vlan_inet_prepare() recently for a similar issue.