netdev - Re: [RFC PATCH] possible bug in handling of ipv4 route caching

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, 8 Apr 2016 09:00:51 -0600
From:	Chris Friesen <chris.friesen@...driver.com>
To:	Julian Anastasov <ja@....bg>
CC:	netdev <netdev@...r.kernel.org>
Subject: Re: [RFC PATCH] possible bug in handling of ipv4 route caching

On 04/07/2016 03:20 PM, Julian Anastasov wrote:
> On Thu, 7 Apr 2016, Chris Friesen wrote:
>
>> Hi,
>>
>> We think we may have found a bug in the handling of ipv4 route caching,
>> and are curious what you think.
>>
>> For local routes that require a particular output interface we do not
>> want to cache the result.  Caching the result causes incorrect behaviour
>> when there are multiple source addresses on the interface.  The end
>> result being that if the intended recipient is waiting on that interface
>> for the packet he won't receive it because it will be delivered on the
>> loopback interface and the IP_PKTINFO ipi_ifindex will be set to the
>> loopback interface as well.

>> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
>> index 02c6229..e965d4b 100644
>> --- a/net/ipv4/route.c
>> +++ b/net/ipv4/route.c
>> @@ -2045,6 +2045,17 @@ static struct rtable *__mkroute_output(const struct fib_result *res,
>>   		 */
>>   		if (fi && res->prefixlen < 4)
>>   			fi = NULL;
>> +	} else if ((type == RTN_LOCAL) && (orig_oif != 0)) {
>
> 	So, we can be more specific. Can this work?:
>
> 	} else if ((type == RTN_LOCAL) && (orig_oif != 0) &&
> 		   (orig_oif != dev_out->ifindex)) {
>
> 	I.e. we should allow to cache orig_oif=LOOPBACK_IFINDEX
> but eth1 should not be cached.

Yes, we think that will work.  New patch to follow.

Chris