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: <1428607284.25985.269.camel@edumazet-glaptop2.roam.corp.google.com>
Date:	Thu, 09 Apr 2015 12:21:24 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	David Miller <davem@...emloft.net>
Cc:	sebastian.poehn@...il.com, netdev@...r.kernel.org
Subject: Re: [FYI] xfrm: Don't lookup sk_policy for timewait sockets

On Thu, 2015-04-09 at 14:37 -0400, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@...il.com>
> Date: Thu, 09 Apr 2015 02:07:41 -0700
> 
> > TCP stack never sends packets attached to a socket in timewait state.
> 
> TPROXY assigns timewait sockets to skb->sk, that's the bug.
> 
> In net/netfilter/xt_TPROXY.c:
> 
> 	tproxy_tg4()
>  ...
> 		sk = nf_tproxy_get_sock_v4(dev_net(skb->dev), iph->protocol,
> 				   iph->saddr, iph->daddr,
> 				   hp->source, hp->dest,
> 				   skb->dev, NFT_LOOKUP_ESTABLISHED);
> 	/* NOTE: assign_sock consumes our sk reference */
> 	if (sk && tproxy_sk_is_transparent(sk)) {
> 		/* This should be in a separate target, but we don't do multiple
> 		   targets on the same rule yet */
> 		skb->mark = (skb->mark & ~mark_mask) ^ mark_value;
> 
> 		pr_debug("redirecting: proto %hhu %pI4:%hu -> %pI4:%hu, mark: %x\n",
> 			 iph->protocol, &iph->daddr, ntohs(hp->dest),
> 			 &laddr, ntohs(lport), skb->mark);
> 
> 		nf_tproxy_assign_sock(skb, sk);
>  ...
>  /* assign a socket to the skb -- consumes sk */
> static void
> nf_tproxy_assign_sock(struct sk_buff *skb, struct sock *sk)
> {
> 	skb_orphan(skb);
> 	skb->sk = sk;
> 	skb->destructor = sock_edemux;
> }


Right, but stack trace shown by Sebastian seems to be an input frame,
and we transmit a frame. This is the part I do not understand, yet.



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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ