systemd-networkd's dhcp4 client ignores local subnet routes
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
systemd (Ubuntu) |
Fix Released
|
Low
|
Unassigned | ||
Jammy |
Fix Released
|
Low
|
Unassigned | ||
Kinetic |
Fix Released
|
Low
|
Unassigned |
Bug Description
[Impact]
If a DHCP server pushes down a local subnet route with a null gateway, the systemd-networkd DHCP client does not correctly install the route. Instead, the route is ignored.
[Test Plan]
Taken from https:/
* Start a Jammy LXD container:
$ lxc launch ubuntu-daily:jammy jammy
$ lxc exec jammy bash
* Create a veth pair:
$ ip link add veth0 up type veth peer name veth1
$ ip addr add 172.20.0.1/24 dev veth0
$ cat > /etc/netplan/
network:
version: 2
ethernets:
veth1:
dhcp4: true
EOF
* Start dnsmasq in the background with the following routes specified:
$ dnsmasq -kq -C /dev/null -z -i veth0 -I lo -F 172.20.
* Apply the netplan config:
$ netplan generate && netplan apply
* Check the routing table (may take a few seconds to update):
$ ip route
[...]
* On an affected system, the route for 169.254.0.0/24 is missing.
[Where problems could occur]
This patch is in the systemd-networkd DHCP client. It adds logic to install routes with a link scope whenever the DHCP server pushes local subnet routes with a null gateway. If any problems occurred, it would related to systemd-networkd's handling of such routes pushed from a DHCP server.
[Original Description]
RFC3442 specifies option 121 (Classless Static Routes) that allow a DHCP server to push arbitrary routes to a client. It has a Local Subnet Routes section expliciting the behavior of routes with a null (0.0.0.0) gateway.
Such routes are to be installed on the interface with a Link scope, to mark them as directly available on the link without any gateway.
Networkd currently drops those routes, which is against the RFC, as Linux has proper support for such routes.
This has been observed as broken on Ubuntu Jammy 22.04 LTS, but working in previous LTS (Focall 20.04 and Bionic 18.04 tested).
1. Ubuntu release: 22.04.1 LTS
2. Systemd release: 249.11-0ubuntu3.6
3. Expected behavior: routes from DHCP option 121 with a gateway set to 0.0.0.0 to be installed as "scope link"
4. Observed behavior: routes are silently dropped by systemd-networkd's dhcp client (actually logged with a debug level, effectively silently with the default configuration)
I wrote a fix that has been accepted in upstream systemd: https:/
As this is a fix for something that is an actual regression, can it be backported to Ubuntu 22.04's systemd tree?
Thanks.
Related branches
- Lukas Märdian: Approve
-
Diff: 983 lines (+913/-0)11 files modifieddebian/changelog (+31/-0)
debian/patches/CVE-2022-4415.patch (+380/-0)
debian/patches/CVE-2022-45873.patch (+115/-0)
debian/patches/backport-for-CVE-2022-45873.patch (+45/-0)
debian/patches/lp2002445/sd-netlink-add-a-test-for-rtnl_set_link_name.patch (+66/-0)
debian/patches/lp2002445/sd-netlink-do-not-swap-old-name-and-alternative-name.patch (+54/-0)
debian/patches/lp2002445/sd-netlink-restore-altname-on-error-in-rtnl_set_link_name.patch (+64/-0)
debian/patches/lp2002445/udev-attempt-device-rename-even-if-interface-is-up.patch (+61/-0)
debian/patches/lp2002445/udev-net-allow-new-link-name-as-an-altname-before-renamin.patch (+34/-0)
debian/patches/lp2004478-network-dhcp4-accept-local-subnet-routes-from-DHCP.patch (+54/-0)
debian/patches/series (+9/-0)
- Lukas Märdian: Approve
-
Diff: 120 lines (+92/-0)4 files modifieddebian/changelog (+13/-0)
debian/patches/lp2004478-network-dhcp4-accept-local-subnet-routes-from-DHCP.patch (+55/-0)
debian/patches/sd-netlink-skip-test_rtnl_set_link_name-when-altnames-are.patch (+22/-0)
debian/patches/series (+2/-0)
- Lukas Märdian: Approve
-
Diff: 506 lines (+442/-0)10 files modifieddebian/changelog (+22/-0)
debian/patches/lp2000880-network-create-stacked-netdevs-after-the-underlying-link-.patch (+33/-0)
debian/patches/lp2002445/sd-netlink-add-a-test-for-rtnl_set_link_name.patch (+81/-0)
debian/patches/lp2002445/sd-netlink-do-not-swap-old-name-and-alternative-name.patch (+54/-0)
debian/patches/lp2002445/sd-netlink-restore-altname-on-error-in-rtnl_set_link_name.patch (+64/-0)
debian/patches/lp2002445/udev-attempt-device-rename-even-if-interface-is-up.patch (+63/-0)
debian/patches/lp2002445/udev-net-allow-new-link-name-as-an-altname-before-renamin.patch (+36/-0)
debian/patches/lp2004478-network-dhcp4-accept-local-subnet-routes-from-DHCP.patch (+54/-0)
debian/patches/lp2009502-Enable-dev-sgx_vepc-access-for-the-group-sgx.patch (+27/-0)
debian/patches/series (+8/-0)
I haven't tested to confirm the broken behavior on jammy, but the patch looks straight forward. To help the process along, could you try to provide some simple steps to reproduce the bug on jammy?