netdev - Re: race in skb_splice

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: <20080528141104.GA5543@2ka.mipt.ru>
Date:	Wed, 28 May 2008 18:11:04 +0400
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	Octavian Purdila <opurdila@...acom.com>
Cc:	Ben Hutchings <bhutchings@...arflare.com>, netdev@...r.kernel.org,
	davem@...emloft.net
Subject: Re: race in skb_splice_bits?

On Wed, May 28, 2008 at 04:20:55PM +0300, Octavian Purdila (opurdila@...acom.com) wrote:
> > I preserved old semantic, when we free skb  
> > only if we read it whole or in case of fin. With your changes we can
> > also free skb, if it was partially consumed 
> 
> If the skb was partially consumed then tcp_recv_skb(seq-1) will return the 
> same skb and the offset +1 != skb->len, thus we will not free it.

I understand now, please correct me if I got your idea wrong.
We only ned to search for the skb again only in case we processed it and
it was possible that socket lock was dropped. So, the only needed place
to put tcp_recv_skb() is where you pointed. Next, to find current skb we
have to get sequence number inside its data, and seq-1 is indeed that
case, even if skb was changed under us (like combined with others), we
still will find it in the queue. Offset in tcp_recv_skb() is set to
number of bytes between starting sequence number for skb and given
sequence number, thus if we search for (seq-1), it will point to the
last byte processed by the code, and thus offset will 'point' to last
processed byte, not byte to start from, so we check against (offset+1)
and if (offset+1) equals to the size of the skb found we can free this
skb (in the code below). If it is not the case and skb contains data
behind (offset+1) we break and the rest of the data will be processed
in the next run. If there is no skb, we just break out of the loop.

So yes, your patch is simpler and faster than mine so you should push it
upstream. Fortunately David Miller is in copy and will (David, will
you?) pick it up and push, likely it is also needed for stable?

> Anyways, I am a newbie in this area, so if my logic doesn't make any sense 
> please be patient with me :)

We all are newbies somewhere and even splice code itself is rather new :)

-- 
	Evgeniy Polyakov
--
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