netdev - Re: [PATCH 2/2] net-timestamp: Make the clone operation stand-alone from phy timestamping

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:	Wed, 03 Sep 2014 19:03:22 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Alexander Duyck <alexander.h.duyck@...el.com>
Cc:	netdev@...r.kernel.org, richardcochran@...il.com,
	davem@...emloft.net, willemb@...gle.com
Subject: Re: [PATCH 2/2] net-timestamp: Make the clone operation stand-alone
 from phy timestamping

On Wed, 2014-09-03 at 16:02 -0700, Alexander Duyck wrote:
> On 09/03/2014 03:05 PM, Eric Dumazet wrote:
> > On Wed, 2014-09-03 at 14:07 -0700, Eric Dumazet wrote:
> > 
> >>
> >> Normally, if one skb holds a reference to a socket, it should have
> >> skb->destructor set to a cleanup function.
> >>
> >> Otherwise, we rely on callers following a convention, to release sk
> >> reference.
> >>
> >> If you believe its needed, it should be dully documented.
> > 
> > 
> > BTW, skb_orphan() would BUG() on this case (skb->destrutor == NULL and
> > skb->sk != NULL)
> 
> That was why we were setting skb->sk to null before passing it to
> sock_queue_err_skb.

Hmpff... This is scary. skb_clone_tx_timestamp() seems the source of
confusion.

>   I think I found the reason why things were done the
> way they were.  It looks like skb_orphan is called in
> sock_queue_err_skb.

Thats standard practice before setting skb->destructor

>   So any destructor added would be fired there before
> before being replaced.

You can use a pair of sock_hold()/sock_put() to guard against early
dismantle. Look at commit da92b194cc36b5dc1fbd 

>  
> 
> The only part I am not sure about is if that would actually be any sort
> of issue.  Do we really need to hold the extra reference to the socket
> all the way through the sock_queue_err_skb call or can we just let it
> get dropped with the call to skb_orphan and let the fact that the
> message is being queued be good enough?


> I'm not sure due to the comment about "before exiting rcu section, make
> sure dst is refcounted".  It kind of implies I should be able to hand
> off the reference counts without worrying about the socket being freed
> out from under me.

Thats a different concern : dst in input path are rcu protected.

If we queue one skb with an attached dst, we must take a refcount on the
dst, or risk the dst being freed under us, by the time we dequeue
packet.

That will not prevent sk from being destroyed.


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html