netdev - [Possible regression?] ip route deletion behavior change

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

Message-ID: <603d815f-f6db-3967-c0df-cbf084a1cbcd@os-cillation.de>
Date:   Thu, 31 Oct 2019 16:44:25 +0100
From:   Hendrik Donner <hd@...cillation.de>
To:     "David S. Miller" <davem@...emloft.net>,
        Alexey Kuznetsov <kuznet@....inr.ac.ru>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        netdev@...r.kernel.org
Subject: [Possible regression?] ip route deletion behavior change

Hello,

analyzing a network issue on our embedded system product i found a change in behavior 
regarding the removal of routing table entries when an IP address is removed.

On older kernel releases before commit 5a56a0b3a45dd0cc5b2f7bec6afd053a474ed9f5
(simplified example):

Routing table:

# ip r
default via 10.0.2.2 dev enp0s3 proto dhcp src 10.0.2.15 metric 1024
10.0.2.0/24 dev enp0s3 proto kernel scope link src 10.0.2.15
10.0.2.2 dev enp0s3 proto dhcp scope link src 10.0.2.15 metric 1024
10.20.0.0/14 via 10.0.2.2 dev enp0s3 src 10.20.40.100

The last route was manually added with ip r add.

Removing the IP 10.20.40.100 from enp0s3 also removes the last route:

# ip r
default via 10.0.2.2 dev enp0s3 proto dhcp src 10.0.2.15 metric 1024
10.0.2.0/24 dev enp0s3 proto kernel scope link src 10.0.2.15
10.0.2.2 dev enp0s3 proto dhcp scope link src 10.0.2.15 metric 1024

After the mentioned commit - so since v4.10 - the route will no longer be removed. At 
least for my team that's a surprising change in behavior because our system relies on
the old behavior.

Reverting the commit restores the old behavior.

I'm aware that our use case is a bit odd, but according to the commit message commit 
5a56a0b3a45dd0cc5b2f7bec6afd053a474ed9f5 was meant to fix VRF related behavior while
having the described (maybe unintended?) user visible side effect for non-VRF usage.

Is that a regression in routing table management?

Best regards,
Hendrik

(I'm not subscribed to the mailing list, please keep me in replies)