netdev - Re: [Patch net] ipv4: fib: check forwarding before checking send

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:	Sat, 12 Apr 2014 17:52:04 +0800
From:	Rex Ge <lungothrin@...il.com>
To:	Cong Wang <xiyou.wangcong@...il.com>
Cc:	Julian Anastasov <ja@....bg>, 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


On Apr 9, 2014, at 6:55 AM, Cong Wang <xiyou.wangcong@...il.com> wrote:

> Thanks for your reply, David and Julian!
> 
> On Tue, Apr 8, 2014 at 3:15 PM, Julian Anastasov <ja@....bg> wrote:
>>        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.
>> 
> 
> route cache is removed after 3.6, so I don't need to do it?
> 
>>> 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?
>> 
> 
> Yeah, I just noticed that for normal loopback packets its ->dst
> are forced to be kept so that it will not need to lookup route
> again on rx. However, in our case, we redirect the packets
> from veth0 to lo when src_addr == dst_addr, its ->dst is dropped
> after coming out of the network namespace, therefore goes into
> the slow path to validate the reverse path and lookup the route.

If what you say is true, this is exactly where the problem is caused.
  "redirect the packet from veth0 to lo when src_addr == dst_addr”
  “its ->dst is dropped after coming out of the network namespace”
these two does not suppose to happen at the same time.

loopback packets are suppose to be redirected to lo device
of the same network namespace, and ->dst is kept.
if ->dst is dropped, set rp_filter to 2 and enable accept_local,
it should be able to pass “__fib_validate_source” check.

If you do these two at the same time, it is your responsibility to trick
routing into believing “dst_addr” is configured on lo device 
of target namespace and enable accept_local on lo,
or rebuild a “dst_entry” manually.

Throw away the assumption that ->dst is attached with
loopback packet is big for routing, some serious checking is required.


> 
> I think David's point is still valid in this case, __fib_validate_source()
> should not reject the packets. So hmm... the only reason I can find is
> the following code:
> 
>        if (fib_lookup(net, &fl4, &res) == 0) {
>                if (res.type == RTN_UNICAST)
>                        ret = FIB_RES_NH(res).nh_scope >= RT_SCOPE_HOST;
>        }
> 
> where its nh_scope == RT_SCOPE_HOST?
> --
> 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

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