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: <CAJGXZLjLXrUzz4S9C7SqeyszMMyjR6RRu52y1fyh_d6gRqFHdA@mail.gmail.com>
Date: Wed, 3 May 2023 18:01:03 +0300
From: Aleksey Shumnik <ashumnik9@...il.com>
To: netdev@...r.kernel.org, waltje@...lt.nl.mugnet.org, 
	Jakub Kicinski <kuba@...nel.org>, gw4pts@...pts.ampr.org, kuznet@....inr.ac.ru, 
	"willemdebruijn.kernel@...il.com" <willemdebruijn.kernel@...il.com>, gnault@...hat.com
Subject: [BUG] Dependence of routing cache entries on the ignore-df flag

Dear maintainers,

I found such a dependency, if the ignore-df flag is set on the
interface, then entries appear in the routing cache.
You can reproduce it as follows:

# cat /etc/network/interfaces.d/mgre0
auto mgre0
iface mgre0 inet static
address 10.10.10.1
netmask 255.255.255.0
pre-up ip tunnel add mgre0 mode gre key 1 ttl 64 tos inherit
pre-up ethtool -K mgre0 tx off > /dev/null
pre-up ip link set mgre0 mtu 1400
pre-up ip link set mgre0 multicast on
pre-up ip link set mgre0 type gre nopmtudisc
pre-up ip link set mgre0 type gre ignore-df
post-down ip link del mgre0

# ifup mgre0
# ip link set mgre0 arp on
# ip neigh add 10.10.10.2 dev mgre0 lladdr <some ipv4 addr>
# ping 10.10.10.2
# ip route show cache
10.10.10.2 dev mgre0
    cache expires 598sec mtu 1400

Creating mgre interface using the following config. Set arp on (this
is necessary).
Add an entry to the neighbor table for arp routing, specify the
address from the same subnet as the address on the mgre interface.
Ping this address. After that, an entry is added to the routing cache.
It seems that after it was not possible to find a suitable entry in
the routing table for the address 10.10.10.2, before looking at the
arp table, an entry is added to the routing cache.

But the most incomprehensible thing for me is if you remove the
ignore-df flag, restart (ifdown, ifup) the interface, then the problem
is not observed, that is, entries are not added to the routing cache.
The answer to the question of how the ignore-df flag  and adding
entries to the routing cache is connected, I have not found.

On the one hand, the routing cache has not been supported in linux for
a long time, and there should not be such entries. On the other hand,
when some services are started, they request the routing table via
netlink and the kernel responds by sending not only the entries of the
main routing table, but also the routing cache.
As a result, incorrect routing entries with 0.0.0.0 nexthop address
appear in the peer list of these services.
Of course, it's not difficult to fix it in the services themselves,
but it seems to me that this will be a correction of the consequences
of the problem, and not the cause itself. It seems to me that this is
the wrong behavior.

Might you answer the questions:
1. How the ignore-df flag and adding entries to the routing cache is
connected? In which kernel files may I look to find this connection?
2. Is this behavior wrong?
3. Is there any way to completely disable the use of the routing
cache? (as far as I understand, it used to be possible to set the
rhash_entries parameter to 0, but now there is no such parameter)
4. Why is an entry added to the routing cache if a suitable entry was
eventually found in the arp table (it is added directly, without being
temporarily added to the routing table)?


Regards,
Aleksey

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ