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]
Message-ID: <50FD96E4.1020607@linux-ipv6.org>
Date:	Tue, 22 Jan 2013 04:28:36 +0900
From:	YOSHIFUJI Hideaki <yoshfuji@...ux-ipv6.org>
To:	David Miller <davem@...emloft.net>
CC:	YOSHIFUJI Hideaki <yoshfuji@...ux-ipv6.org>, netdev@...r.kernel.org
Subject: Rate Limitation of Router Reachability Probing for possible dead
 routers (is Re: ipv6: Do not depend on rt->n in rt6_probe().)

(2013年01月22日 03:41), YOSHIFUJI Hideaki wrote:
> (2013年01月22日 03:28), Dan Carpenter wrote:
>> Hello YOSHIFUJI Hideaki / 吉藤英明,
>>
>> This is a semi-automatic email about new static checker warnings.
>>
>> The patch 2152caea7196: "ipv6: Do not depend on rt->n in 
>> rt6_probe()." from Jan 17, 2013, leads to the following Smatch 
>> complaint:
>>
>> net/ipv6/route.c:495 rt6_probe()
>> 	 error: we previously assumed 'neigh' could be null (see line 490)
>>
>> net/ipv6/route.c
>>    489	
>>    490		if (!neigh ||
>>                      ^^^^^
>> New test.
>>
>>    491		    time_after(jiffies, neigh->updated + rt->rt6i_idev->cnf.rtr_probe_interval)) {
>>    492			struct in6_addr mcaddr;
>>    493			struct in6_addr *target;
>>    494	
>>    495			neigh->updated = jiffies;
>>                         ^^^^^^^^^^^^^^
>> Old dereference.
>>
>>    496	
>>    497			if (neigh)
>>                             ^^^^^
>> Another new test.
> 
> Oh, right, I'll fix.  Thanks!

Ok, fix is easy, but in fact, we have broken router reachability
probing.

Here rt->n was neighbour entry for (unreachable) router.
The specification says, we SHOUDLD probe such router, but we
should  have some rate limit (once per minute, or so).

We used "rt->n->updated" for this purpose, but now, if NS failed,
we may immediately removes neighbour entry for it.  So,
we might continue sending NS to dead router every 1 second.

Any ideas?

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ