On Tue, Nov 10, 2026 at 06:15:32AM +0000, liamsmith827 wrote:
From: liamsmith827 <redacted>
For non-vrf unicast, the on-link fallback currently occurs regardless of
the particular error returned by fib_lookup(). As a result, routes and
rules that are supposed to restrict traffic (blackhole, prohibit,
unreachable) are unable to do so comprehensively.
A specific example of this being a problem is within Android, where the
VPN "kill switch" is implemented with prohibit rules. Any process that
can set flowi4_oif (SO_BINDTODEVICE, IP_UNICAST_IF, IP_PKTINFO, etc.) is
able to utilize this fallback, meaning unprivileged Android apps can
trivially bypass the VPN. This is particularly bad on cellular networks,
where ARP is often not needed.
The first patch adds FIB_LOOKUP_REPORT_MISS. IPv4 FIB lookup maps a
routing miss to -ENETUNREACH, which is also returned when an unreachable
rule is encountered. This flag prevents the mapping, returning -ESRCH
instead.
The second patch uses this flag to restrict the fallback to routing
lookup misses for non-vrf unicast. The fallback is still always taken
for multicast, regardless of any restrictions or misses.
The third patch updates tests now that the on-link fallback has been
restricted to routing lookup misses for non-vrf unicast.
The fourth patch replaces an existing comment which describes obsolete
fib_lookup(), MSG_DONTROUTE and IPv6 behavior.
This was originally observed on an Android device, by way of packet
capture.
Tested fcnal-test.sh in UML with CONFIG_IP_MULTIPLE_TABLES both enabled
and disabled.
The cover letter explains the problem and the solution, but it doesn't
list the user visible changes and doesn't explain why we think that it's
safe to make them. Something like [a].
v2:
- Restrict the fallback to routing lookup misses, instead of only
honoring prohibit (-EACCES).
- Add FIB_LOOKUP_REPORT_MISS to differentiate a routing miss from an
unreachable rule.
- Split the comment update out into its own patch and remove the
signature.
- Enable all of the commented out device bind tests in
ipv4_ping_novrf(), add a route miss test and update the UDP test
expectations.
- Target net instead of net-next, add Fixes and Cc stable.
All of the patches should be targeted at net-next, without Fixes tags
and without stable tags. The patches don't fix a regression. More
context here [b].
- Drop RFC.
v1: https://lore.kernel.org/netdev/20261019032406.88874-1-liamsmith827@grapheneos.org/ (local)
[a]
"
When an output interface is specified (e.g., using SO_BINDTODEVICE,
IP_UNICAST_IF or IP_PKTINFO) and the FIB lookup fails, the IPv4 output
path ignores the error and constructs an on-link route via the
specified interface. According to the comment above the code, the
intent was to allow sending packets via an interface that does not have
any routes.
However, the error code is not checked, so the fallback is also taken
when the lookup hits an unreachable, blackhole or prohibit route /
rule. In other words, these routes and rules are ignored when an output
interface is specified [1].
This is a problem for Android, which implements its VPN "kill switch"
using prohibit rules, with the expectation that packets hitting such
rules are never transmitted. Unprivileged applications can bind a
socket to an interface and trivially bypass the VPN. This is especially
bad on cellular interfaces where neighbour resolution is not needed, so
packets can reach any destination and not only on-link ones.
Solve this by only taking the fallback when the lookup did not match
any route (i.e., a miss) and returning the error to the caller
otherwise [2].
It is currently impossible to distinguish between a miss and an
unreachable rule since they both return the same error (-ENETUNREACH).
Therefore, patch #1 adds a lookup flag that makes the lookup return a
different error upon a miss and patch #2 uses it to restrict the
fallback. Patch #3 adjusts the selftests and patch #4 updates the
comment above the fallback.
After the change, a packet that was previously transmitted on-link
despite hitting one of these routes / rules is no longer transmitted
and an error is returned to user space instead. It is unlikely that
anyone is relying on the current behavior:
1. It is a side effect of not checking the error code and it contradicts
ip-route(8) and ip-rule(8), which document these routes and rules as
dropping packets or generating an error.
2. These routes and rules are already honored when the output interface
is a VRF device or enslaved to one.
3. These rules are already honored by IPv6, which does not have such a
fallback.
The following is unchanged:
1. Packets can still be sent via the specified interface when the
lookup does not match any route, which is the original use case.
2. The fallback is still always taken for multicast packets. This is
required for multicast to work in a VRF, where the lookup hits the
unreachable default route in the VRF table.
[1]
# ip link add name dummy1 up type dummy
# ip address add 192.0.2.1/24 dev dummy1
# ip rule add to 198.51.100.1 prohibit
# ip route get 198.51.100.1
RTNETLINK answers: Permission denied
# ip route get 198.51.100.1 oif dummy1
198.51.100.1 dev dummy1 src 192.0.2.1 uid 0
cache
[2]
# ip route get 198.51.100.1 oif dummy1
RTNETLINK answers: Permission denied
"
[b] https://lore.kernel.org/netdev/20261030151629.GA85001@shredder/ (local)