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]

Date:	Wed, 28 May 2008 18:20:02 +0300
From:	Octavian Purdila <opurdila@...acom.com>
To:	Evgeniy Polyakov <johnpol@....mipt.ru>
Cc:	Ben Hutchings <bhutchings@...arflare.com>, netdev@...r.kernel.org,
	davem@...emloft.net
Subject: Re: race in skb_splice_bits?

On Wednesday 28 May 2008, Evgeniy Polyakov 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
<snip>

Yes, that is correct. 

> 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?
>

OK, will clean it up and post a proper patch soon. Which tree should I base it 
on?

Thanks,
tavi
--
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