netdev - Re: VRF/IPv4/ARP: unregister_netdevice waiting for dev to become free -> Who's responsible for releasing dst_entry created by ip_route_input

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]

Message-ID: <354f3931-1a9a-fff2-182c-d470fe46776a@gmail.com>
Date:   Sat, 5 Jun 2021 17:00:55 -0600
From:   David Ahern <dsahern@...il.com>
To:     Oliver Herms <oliver.peter.herms@...il.com>,
        Network Development <netdev@...r.kernel.org>
Cc:     David Miller <davem@...emloft.net>
Subject: Re: VRF/IPv4/ARP: unregister_netdevice waiting for dev to become free
 -> Who's responsible for releasing dst_entry created by ip_route_input_noref?

On 6/5/21 11:16 AM, Oliver Herms wrote:
> Processing the incoming ARP request causes a call to ip_route_input_noref => ip_route_input_rcu => ip_route_input_slow => rt_dst_alloc => dst_alloc => dev_hold.
> In a non VRF use-case the dst->dev would be the loopback interface that is never deleted. In the VRF use-case dst->dev is the VRF interface. And that one I would like to delete.
> 
> I've tracked down that dst_release() would call dev_put() but it seems dst_release is not called here (but should be I guess?). Thus, causing a dst_entry leak that causes the VRF device to be unremovable.
> At least that's what it looks like to me.
> 

I see what the problem is -- rtable is on cached on the l3mdev port
device. I have an idea how to fix it; I will send a patch within a few
days. Thanks for the detailed analysis and report.