netdev - Re: [PATCH net 2/4] gro: fix ownership transfer

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]

Date: Mon, 18 Mar 2024 10:09:40 +0100
From: Antoine Tenart <atenart@...nel.org>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>, davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com
Cc: steffen.klassert@...unet.com, netdev@...r.kernel.org
Subject: Re: [PATCH net 2/4] gro: fix ownership transfer

Quoting Willem de Bruijn (2024-03-16 16:25:13)
> Antoine Tenart wrote:
> > Issue was found while using rx-gro-list. If fragmented packets are GROed
> 
> Only if you need to respin: "If packets are GROed with fraglist"
> 
> A bit pedantic, but this is subtle stuff. These are not IP fragmented
> packets. Or worse, UDP fragmentation offload.

Right, that was only describing which kind of packets were GROed in my
test. Looks like that's confusing, I'll remove it.

> > in skb_gro_receive_list, they might be segmented later on and continue
> > their journey in the stack. In skb_segment_list those skbs can be reused
> > as-is. This is an issue as their destructor was removed in
> > skb_gro_receive_list but not the reference to their socket, and then
> > they can't be orphaned. Fix this by also removing the reference to the
> > socket.
> > 
> > For example this could be observed,
> > 
> >   kernel BUG at include/linux/skbuff.h:3131!  (skb_orphan)
> >   RIP: 0010:ip6_rcv_core+0x11bc/0x19a0
> >   Call Trace:
> >    ipv6_list_rcv+0x250/0x3f0
> >    __netif_receive_skb_list_core+0x49d/0x8f0
> >    netif_receive_skb_list_internal+0x634/0xd40
> >    napi_complete_done+0x1d2/0x7d0
> >    gro_cell_poll+0x118/0x1f0
> > 
> > A similar construction is found in skb_gro_receive, apply the same
> > change there.
> > 
> > Fixes: 5e10da5385d2 ("skbuff: allow 'slow_gro' for skb carring sock reference")
> > Signed-off-by: Antoine Tenart <atenart@...nel.org>
> 
> Looks fine to me on the understanding that the only GSO packets that
> arrive with skb->sk are are result of the referenced commit, and thus
> had sock_wfree as destructor.

The root cause of the issue is a disparity between skb->destructor and
skb->sk; either skb with skb->{destructor,sk} could arrive there and
that was not an issue, or they could not. In both cases the above commit
is introducing that behavior.

Thanks!
Antoine