linux-kernel - Re: [PATCH net] udp: fix segmentation crash for GRO packet without fraglist

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]

Date: Mon, 29 Apr 2024 17:14:58 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Daniel Borkmann <daniel@...earbox.net>, 
 Lena Wang (王娜) <Lena.Wang@...iatek.com>, 
 "maze@...gle.com" <maze@...gle.com>, 
 "willemdebruijn.kernel@...il.com" <willemdebruijn.kernel@...il.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, 
 "bpf@...r.kernel.org" <bpf@...r.kernel.org>, 
 "steffen.klassert@...unet.com" <steffen.klassert@...unet.com>, 
 "kuba@...nel.org" <kuba@...nel.org>, 
 Shiming Cheng (成诗明) <Shiming.Cheng@...iatek.com>, 
 "pabeni@...hat.com" <pabeni@...hat.com>, 
 "edumazet@...gle.com" <edumazet@...gle.com>, 
 "netdev@...r.kernel.org" <netdev@...r.kernel.org>, 
 "matthias.bgg@...il.com" <matthias.bgg@...il.com>, 
 "davem@...emloft.net" <davem@...emloft.net>, 
 "yan@...udflare.com" <yan@...udflare.com>
Subject: Re: [PATCH net] udp: fix segmentation crash for GRO packet without
 fraglist

> >> The 'write_len > skb_headlen(skb)' test is redundant, no ?
> >>
> >> It is covered by the earlier test :
> >>
> >>           if (likely(len <= skb_headlen(skb)))
> >>                   return SKB_NOT_DROPPED_YET;
> >>
> > Daniel, it is not redundant. The bpf pulls a len between
> > skb_headlen(skb) and skb->len that results in error. Here it will stop
> > this operation. For other skbs(not SKB_GSO_FRAGLIST) it could be a
> > normal behaviour and will continue to do next pulling.
> 
> I meant something like the below. The len <= skb_headlen(skb) case you
> already return earlier with SKB_NOT_DROPPED_YET. Willem, do you see a
> case where this should not live in pskb_may_pull_reason() but rather
> specifically in skb_ensure_writable()?

Yes. pskb_may_pull is called all over the hot path. All in locations
that are known safe, because they only pull header bytes. I prefer to
limit the branch to the few (user configurable) locations that are in
scope.