netdev - Re: [RFC net-next] net: guard drivers against shared skbs

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, 15 Nov 2021 09:35:12 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Eric Dumazet <eric.dumazet@...il.com>
Cc:     davem@...emloft.net, netdev@...r.kernel.org, hawk@...nel.org,
        syzbot+4c63f36709a642f801c5@...kaller.appspotmail.com
Subject: Re: [RFC net-next] net: guard drivers against shared skbs

On Mon, 15 Nov 2021 08:56:10 -0800 Eric Dumazet wrote:
> On 11/15/21 8:32 AM, Jakub Kicinski wrote:
> > Commit d8873315065f ("net: add IFF_SKB_TX_SHARED flag to priv_flags")
> > introduced IFF_SKB_TX_SHARED to protect drivers which are not ready
> > for getting shared skbs from pktgen sending such frames.
> > 
> > Some drivers dutifully clear the flag but most don't, even though
> > they modify the skb or call skb helpers which expect private skbs.
> > 
> > syzbot has also discovered more sources of shared skbs than just
> > pktgen (e.g. llc).
> > 
> > I think defaulting to opt-in is doing more harm than good, those
> > who care about fast pktgen should inspect their drivers and opt-in.
> > It's far too risky to enable this flag in ether_setup().

> > diff --git a/net/core/dev.c b/net/core/dev.c
> > index 15ac064b5562..476a826bb4f0 100644
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -3661,6 +3661,10 @@ static struct sk_buff *validate_xmit_skb(struct sk_buff *skb, struct net_device
> >  	if (unlikely(!skb))
> >  		goto out_null;
> >  
> > +	if (unlikely(skb_shared(skb)) &&
> > +	    !(dev->priv_flags & IFF_TX_SKB_SHARING))
> > +		goto out_kfree_skb;  
> 
> So this will break llc, right ?

Likely. I haven't checked why LLC thinks it's a good idea to send
shared skbs, probably convenience.

> I am sad we are adding so much tests in fast path.

What's our general stance on shared skbs in the Tx path? If we think
that it's okay maybe it's time to turn the BUG_ON(shared_skb)s in pskb
functions into return -EINVALs?

The IFF_TX_SKB_SHARING flag is pretty toothless as it stands.