netdev - Martian source when routing packets through ipvlan device with loose rp

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

Message-ID: <CAEA9r7AR9DwbophLeJ4ScggYako=YfBtRYgd5TfCfNfovw24HA@mail.gmail.com>
Date: Wed, 15 May 2024 23:48:34 +0200
From: "Emil.s" <emil.sandnabba@...il.com>
To: netdev@...r.kernel.org
Subject: Martian source when routing packets through ipvlan device with loose
 rp_filter on parent interface

Hello!

I've found what I think might be a bug in the reverse path filtering,
when used in combination with ipvlan devices.

As a simple example I've setup an environment with one client and one gateway:

Gateway:
* ens4f0: 10.1.1.1/16 (Physical interface)
* usb0 (Physical interface - 8c:ae:4c:fe:00:a7)
* ipvlan_usb@...0: 192.168.0.1/24 (ipvlan mode l2/bridge)

Gateway routing table:
gateway #> ip ro
10.1.0.0/16 dev ens4f0 proto kernel scope link src 10.1.1.1
192.168.0.0/24 dev ipvlan_usb proto kernel scope link src 192.168.0.1

Client:
* eth0 (58:ef:68:b5:0d:46): 192.168.0.1/24
* `ip route add 10.1.0.0/16 via 192.168.0.1`

Client routing table:
client #> ip ro
10.1.0.0/16 via 192.168.0.1 dev eth0
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.2

>From the client, I can ping the gateway without any issues
(192.168.0.1). But when I try to ping 10.1.1.1, the packets are just
dropped with the following log lines shown on the gateway:
kernel: IPv4: martian source 10.1.1.1 from 192.168.0.2, on dev usb0
kernel: ll header: 00000000: 8c ae 4c fe 00 a7 58 ef 68 b5 0d 46 08 00

I would expect this behavior using strict reverse path filtering,
since the packet will enter the usb0 interface, but the IP and route
belong to a sub-interface.
But in my case, I'm using "2 - loose mode" that states: "Each incoming
packet's source address is also tested against the FIB and if the
source address is not reachable via any interface the packet check
will fail."
As seen in the routing table, I do have a route to both subnets, so I
should get a match in my FIB.

Disabling rp_filter (0) on the 'usb0' interface solves the issue, and
packets will get routed normally. Another workaround is to delete the
kernel route from the ipvlan device and manually adding it to the
physical device:
gateway #> ip ro del 192.168.0.0/24 dev ipvlan_usb
gateway #> ip ro add 192.168.0.0/24 dev usb0

I've tested this on both Linux 5.15 on Ubuntu 22.04, as well as Linux
6.8.9 on Arch linux with the same result.
I hope I got this right, It's my first time mailing the kernel mailing lists.

Best regards

Emil Sandnabba