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  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, 9 Apr 2014 01:15:48 +0300 (EEST)
From:	Julian Anastasov <ja@....bg>
To:	Cong Wang <xiyou.wangcong@...il.com>
cc:	David Miller <davem@...emloft.net>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Cong Wang <cwang@...pensource.com>
Subject: Re: [Patch net] ipv4: fib: check forwarding before checking
 send_redirects


	Hello,

On Tue, 8 Apr 2014, Cong Wang wrote:

> I must miss something here. Looking at the code:
> 
>         int r = secpath_exists(skb) ? 0 : IN_DEV_RPFILTER(idev);
> 
>         if (!r && !fib_num_tclassid_users(dev_net(dev)) &&
>             (dev->ifindex != oif || !IN_DEV_TX_REDIRECTS(idev))) {
>                 *itag = 0;
>                 return 0;
>         }
> 
> r == 0 is true in our case since we disable rp_filter manually.
> And fib_num_tclassid_users() == 0 by default too.
> 
> Therefore, the only thing takes effect is if dev->ifindex == oif.
> Given the fact that disabling send_redirects makes the problem
> disappear, dev->ifindex != oif must be false, otherwise it doesn't
> even need to check TX_REDIRECTS.
> 
> The rx interface is loopback, so skb->dev == lo, and the oif we pass
> here must be LOOPBACK_IFINDEX, therefore the following code
> in ip_route_input_slow():

	Yes, the code will fail if input route is
tried on loopback device. My first thought was that
you forgot to 'ip route flush cache' after clearing
rp_filter.

> which looks good to me too, since the packet has src addr == dst addr.
> 
> Which part am I missing?

	What kind of packet is that and why the skb lost its
output route and now it is trying for input route?

Regards

--
Julian Anastasov <ja@....bg>
--
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