netdev - Re: Stale entries in RT_TABLE

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:	Thu, 10 Mar 2011 03:50:27 +0200 (EET)
From:	Julian Anastasov <ja@....bg>
To:	David Miller <davem@...emloft.net>
cc:	alexandre.sidorenko@...com, netdev@...r.kernel.org
Subject: Re: Stale entries in RT_TABLE_LOCAL


 	Hello,

On Thu, 10 Mar 2011, Julian Anastasov wrote:

> On Wed, 9 Mar 2011, David Miller wrote:
>
>> From: Alex Sidorenko <alexandre.sidorenko@...com>
>> Date: Wed, 23 Feb 2011 12:43:23 -0500
>> 
>>> I am not sure what is the best way to fix this, I can think of several
>>> approaches:
>>>
>>>   (a) change the sources so that it would be impossible to add the same IP
>>>       multiple times, even with different masks. I cannot think of any
>>>       situation where adding the same IP (but with different mask) to the 
>>> same
>>>       interface could be useful. But maybe I am wrong?
>> 
>> I'm leaning towards this solution if it's viable.  But I'm not so sure that
>> nobody uses this feature, maybe Julian knows?
>> 
>> Julian, the issue is that if you add the same IP address multiple times 
>> using
>> different subnet masks, we allow it.
>> 
>> But removal doesn't work correctly, we clear the IFA list on the device but 
>> we
>> leave stale entries in the local routing table.
>> 
>> The test case is:
>> 
>> ip addr add 192.168.142.109/23 dev dummy0
>> ip addr add 192.168.142.109/22 dev dummy0
>
> 	Here I have just one local route.

 	Aha, it seems the problem happens when the
both lines are executed while there is another address on
device and the last added address becomes secondary
for the 1st, eg:

IP1: 192.168.140.31/22, primary
IP2: 192.168.142.109/23, primary
IP3: 192.168.142.109/22, secondary for primary IP1

 	It is the route for IP3 that is leaked, with prefsrc=IP1.
We create local route for secondary IPs with prefsrc=ItsPrimaryIP.
Both local routes for 109 differ in prefsrc (fa_info). But on
deletion only one route is deleted due to last_ip check - the first
because on deletion prefsrc is not matched, fib_table_delete
does not work in symmetric way. So, the local route created
for IP3 remains no matter the deletion order.
If we decide to create one unique local route for this case,
there is a risk device unregistration to remove
it (fib_sync_down_dev with force > 0). I have to think more
on this issue...

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