netdev - Re: v5.2: stuck ipv4 redirects

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] [day] [month] [year] [list]

Date:   Thu, 12 Dec 2019 11:59:36 +0000
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     netdev@...r.kernel.org
Subject: Re: v5.2: stuck ipv4 redirects

On Thu, Dec 12, 2019 at 11:44:52AM +0000, Russell King - ARM Linux admin wrote:
> Hi,
> 
> I'm seeing a problem with ipv4 redirects seemingly not expiring.
> 
> I have:
> - A VM running a 5.2 kernel, with IP address 192.168.0.251/23, default
>   route 192.168.0.254.
> - The main router at 192.168.0.254/23.
> - A second router which was at 192.168.1.59/23, but which I moved to
>   192.168.0.245/23.  Behind this is a subnet 192.168.253.252/30.
> 
> The VM at some point received a redirect from 192.168.0.254 for
> 192.168.253.254, telling it to redirect to 192.168.1.59.
> 
> Since the IP change of the second router, the VM has been unable to
> contact 192.168.253.254, but can contact 192.168.253.253.  What I
> see via tcpdump is:
> 
> 11:34:48.549410 ARP, Request who-has 192.168.1.59 tell 192.168.0.251, length 28
> 
> I haven't found a way to view any information on the redirects that
> the VM kernel has accepted.  The `ip' tool doesn't seem to have any
> way to access that information (or I'm missing something.)
> 
> Any ideas what is going on, how to inspect the kernel's state from
> userland wrt redirects, and how this can be solved without rebooting?

It seems others have come across this as well:

http://commandline.ninja/2015/06/18/damn-you-icmp-redirect-or-rather-how-to-flush-a-cached-icmp-redirect-under-centos7linux/

and with that, I've a way to "solve" the problem - but it seems that
some redirects can get stuck:

$ ip -s route get 192.168.253.254
192.168.253.254 via 192.168.1.59 dev enp1s0 src 192.168.0.251 uid 1000
    cache <redirected> users 2
$ ip -s route get 192.168.253.253
192.168.253.253 via 192.168.0.245 dev enp1s0 src 192.168.0.251 uid 1000
    cache <redirected> expires 274sec users 2 age 24sec

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up