netdev - VRF Routing Rule Matching Issue: oif Rules Not Working After Commit 40867d74c374

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: <ec671c4f821a4d63904d0da15d604b75@huawei.com>
Date: Thu, 3 Apr 2025 01:58:46 +0000
From: hanhuihui <hanhuihui5@...wei.com>
To: "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "dsahern@...nel.org"
	<dsahern@...nel.org>, "kuba@...nel.org" <kuba@...nel.org>
Subject: VRF Routing Rule Matching Issue: oif Rules Not Working After Commit
 40867d74c374

Dear Kernel Community and Network Maintainers,
I am analyzing the issue, and I am very happy for any replies.
After the application committed 40867d74c374 ("net: Add l3mdev index to flow struct and avoid oif reset for port devices"), we noticed an unexpected change in VRF routing rule matching behavior. We hereby submit a problem report to confirm whether this is the expected behavior.

Problem Description:
When interfaces bound to multiple VRFs share the same IP address, the OIF (output interface) routing rule is no longer matched after being committed. As a result, traffic incorrectly matches the low-priority rule.
Here are our configuration steps:
ip address add 11.47.3.130/16 dev enp4s0
ip address add 11.47.3.130/16 dev enp5s0

ip link add name vrf-srv-1 type vrf table 10
ip link set dev vrf-srv-1 up
ip link set dev enp4s0 master vrf-srv-1

ip link add name vrf-srv type vrf table 20
ip link set dev vrf-srv up
ip link set dev enp5s0 master vrf-srv

ip rule add from 11.47.3.130 oif vrf-srv-1 table 10 prio 0
ip rule add from 11.47.3.130 iif vrf-srv-1 table 10 prio 0
ip rule add from 11.47.3.130 table 20 prio 997

In this configuration, when the following commands are executed:
ip vrf exec vrf-srv-1 ping "11.47.9.250" -I 11.47.3.130
Expected behavior: The traffic should match the oif vrf-srv-1 rule of prio 0. Table 10 is used.
Actual behavior: The traffic skips the oif rule and matches the default rule of prio 997 (Table 20), causing the ping to fail.

Is this the expected behavior?
The submission description mentions "avoid oif reset of port devices". Does this change the matching logic of oif in VRF scenarios?
If this change is intentional, how should the VRF configuration be adjusted to ensure that oif rules are matched first? Is it necessary to introduce a new mechanism?