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:	Sat, 12 Apr 2014 17:52:04 +0800
From:	Rex Ge <>
To:	Cong Wang <>
Cc:	Julian Anastasov <>, David Miller <>,
	Linux Kernel Network Developers <>,
	"Eric W. Biederman" <>,
	Cong Wang <>
Subject: Re: [Patch net] ipv4: fib: check forwarding before checking send_redirects

On Apr 9, 2014, at 6:55 AM, Cong Wang <> wrote:

> Thanks for your reply, David and Julian!
> On Tue, Apr 8, 2014 at 3:15 PM, Julian Anastasov <> 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
> More majordomo info at

To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists