netdev - Re: [PATCH net-next] net: bail on sock_wfree, sock_rfree when we have a TCP

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:	Fri, 03 Jul 2015 06:45:01 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Alex Gartrell <alexgartrell@...il.com>
Cc:	Julian Anastasov <ja@....bg>, Eric Dumazet <edumazet@...gle.com>,
	David Miller <davem@...emloft.net>,
	"agartrell@...com" <agartrell@...com>,
	netdev <netdev@...r.kernel.org>, kernel-team <kernel-team@...com>
Subject: Re: [PATCH net-next] net: bail on sock_wfree, sock_rfree when we
 have a TCP_TIMEWAIT sk

On Thu, 2015-07-02 at 14:18 -0700, Alex Gartrell wrote:
> On Thu, Jul 2, 2015 at 1:44 AM, Julian Anastasov <ja@....bg> wrote:
> >         I think, your patch from January is almost
> > good:
> 
> I'll rebase it, add your other suggestions, test it, and send it in.
> 
> > And the patch from Eric for IPVS looks good too.
> 
> Are we sure that we want to change the semantics of set_owner_w to
> orphan it?  It works for us but that's not the behavior I'd expect
> from that function and might burn someone later?

I do not understand the concern.

skb_set_owner_w() callers are attempting to :

1) Remove association of a previous socket (skb_orphan()), if it was
there (while most skb at this point are not associated with a previous
socket)

2) Attach skb to a socket.

My fix makes sure this new socket is not a timewait or request sock.

This could happen when routes are changed in a malicious way,
because in early demux, socket dst cache is not valid anymore,
but we keep skb->sk set.

(This could happen without ipvs being in the picture I think)

Bug could happen for example if 
A) GRO cooks a GRO packet
B) we find a timewait socket and attach it to skb (and soon we also
might find a syn_recv socket)
C) Route decides to forward packet
D) output interface needs to add some headroom, check for example
net/ipv6/ip6_gre.c around lines 699





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