netdev - Re: [PATCH net] net: orphan frags on stand-alone ptype in dev_queue_xmit

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: <1506121446.29839.177.camel@edumazet-glaptop3.roam.corp.google.com>
Date:   Fri, 22 Sep 2017 16:04:06 -0700
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Willem de Bruijn <willemb@...gle.com>
Cc:     netdev@...r.kernel.org, davem@...emloft.net
Subject: Re: [PATCH net] net: orphan frags on stand-alone ptype in
 dev_queue_xmit_nit

On Fri, 2017-09-22 at 18:51 -0400, Willem de Bruijn wrote:
> Zerocopy skbs frags are copied when the skb is looped to a local sock.
> Commit 1080e512d44d ("net: orphan frags on receive") introduced calls
> to skb_orphan_frags to deliver_skb and __netif_receive_skb.
> 
> With msg_zerocopy, these skbs can also exist in the tx path and thus
> loop from dev_queue_xmit_nit. This already calls deliver_skb in its
> loop. But it does not orphan before a separate pt_prev->func().
> 
> Add the missing skb_orphan_frags_rx.
> 
> Fixes: 1f8b977ab32d ("sock: enable MSG_ZEROCOPY")
> Signed-off-by: Willem de Bruijn <willemb@...gle.com>
> ---
>  net/core/dev.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 9a2254f9802f..3f5b26ff4f74 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -1948,7 +1948,7 @@ void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev)
>  		goto again;
>  	}
>  out_unlock:
> -	if (pt_prev)
> +	if (pt_prev && !skb_orphan_frags_rx(skb2, GFP_ATOMIC))
>  		pt_prev->func(skb2, skb->dev, pt_prev, skb->dev);

Don't you need to kfree_skb(skb2) in case of failure ?

>  	rcu_read_unlock();
>  }