netdev - Re: 3.0: unexpected route cache entry for wrong segment?

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: <4F3BABD3.5070404@msgid.tls.msk.ru>
Date:	Wed, 15 Feb 2012 16:57:55 +0400
From:	Michael Tokarev <mjt@....msk.ru>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	netdev <netdev@...r.kernel.org>, David Miller <davem@...emloft.net>
Subject: Re: 3.0: unexpected route cache entry for wrong segment?

On 15.02.2012 16:46, Eric Dumazet wrote:
> Le mercredi 15 février 2012 à 16:10 +0400, Michael Tokarev a écrit :
>
>> David, any progress with these?
>>
>> 7cc9150ebe8ec06cafea9f1c10d92ddacf88d8ae "route: fix ICMP redirect validation"
>> applies correctly to 3.0, but 9cc20b268a5a14f5e57b8ad405a83513ab0d78dc
>> "ipv4: fix redirect handling" does not, due to some changes in-between,
>> but these should be easy to sort out.  Should I perhaps refresh this
>> patch myself?  It should be doable, I think.
>
> I totally screwed up when I said that, I was mixing things.

Oh ok.  However at least the first patch (fix ICMP redirect validation)
appears to be quite relevant here.  And the second patch is also about
the very same area.

> Can you reproduce this problem with latest 3.0.21 ?

As I described before, it was the only occurence of this issue here.
I wasn't able to reproduce it by sending "bad" ICMP redirects to the
host in question (running 3.0.18).  The host still hasn't been rebooted,
it is still running the same 3.0.18, but after the neigh entry expired
there hasn't been any other similar issues.  Or at least not the ones
I actually seen -- it's been one case which looked the same but I haven't
seen it really, when I looked it's been gone already since the remote
machine were turned off and the entry has expired (it was from the same
remote segment btw).

Since I still don't understand where that entry (caused by what? stray
ICMP redirect? Something else?) come from in the first place, nor do I
know how to reproduce this, I'm just waiting and watching.

3.0.21 included "net: fix NULL dereferences in check_peer_redir()" patch
(which is somewhat large(ish) - I wonder why it has been rolled into
single patch while in reality it consists of 7 commits; and I wonder
why the final result is different from current version in check_peer_redir()
routine, which I mentioned in my other email in this thread), but that
one does not seem to address this very issue - from a quick view anyway.

Thank you!

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