netdev - net: ipconfig: dev_set_mtu call is incompatible with a number of Ethernet drivers

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <f532722f-d1ea-d8fb-cf56-da55f3d2eb59@threespeedlogic.com>
Date: Thu, 14 Dec 2023 12:07:21 -0800
From: Graeme Smecher <gsmecher@...eespeedlogic.com>
To: davem@...emloft.net, dsahern@...nel.org
Cc: netdev@...r.kernel.org, claudiu.beznea@...on.dev,
 nicolas.ferre@...rochip.com, mdf@...nel.org
Subject: net: ipconfig: dev_set_mtu call is incompatible with a number of
 Ethernet drivers

Hi all,

In a number of ethernet drivers, the MTU can't be changed on a running device. Here's one example (from drivers/net/ethernet/cadence/macb_main.c):

static int macb_change_mtu(struct net_device *dev, int new_mtu)
{
	if (netif_running(dev))
		return -EBUSY;
		dev->mtu = new_mtu;
		return 0;
}

This code is present in a number of other drivers:

- drivers/net/ethernet/renesas/sh_eth.c
- drivers/net/ethernet/cadence/macb_main.c
- drivers/net/ethernet/ni/nixge.c
- drivers/net/ethernet/dlink/sundance.c

In all but nixge, the reasoning is straightforward: device buffers are allocated with a size that depends on MTU, so the device has to be brought down and these buffers re-allocated when the MTU changes. However, the ipconfig code is incompatible with this:

	/* Handle the case where we need non-standard MTU on the boot link (a network
	 * using jumbo frames, for instance).  If we can't set the mtu, don't error
	 * out, we'll try to muddle along.
	 */
	if (ic_dev_mtu != 0) {
		rtnl_lock();
		if ((err = dev_set_mtu(ic_dev->dev, ic_dev_mtu)) < 0)
			pr_err("IP-Config: Unable to set interface mtu to %d (%d)\n",
			       ic_dev_mtu, err);
		rtnl_unlock();
	}

The device is not brought down prior to dev_set_mtu, so we always trigger an -EBUSY with these drivers. The boot log looks like this:

[    6.988410] Sending DHCP requests ., OK
[    8.016248] IP-Config: Got DHCP answer from 192.168.1.1, my address is 192.168.1.217
[    8.023994] IP-Config: Complete:
[    8.027215]      device=eth0, hwaddr=46:b5:da:0d:99:20, ipaddr=192.168.1.217, mask=255.255.255.0, gw=255.255.255.255
[    8.037729]      host=192.168.1.217, domain=threespeedlogic.com, nis-domain=(none)
[    8.045288]      bootserver=192.168.1.1, rootserver=192.168.1.1, rootpath=, mtu=9000
[    8.045296]      nameserver0=192.168.1.1
[    8.057015] IP-Config: Unable to set interface mtu to 9000 (-16)

So - what to do? I can see three defensible arguments:

- The network drivers should allow MTU changes on-the-fly (many do), or
- The ipconfig code could bring the adapter down and up again, or
- This is out-of-scope, and I should be reconfiguring the interface in userspace anyways.

thanks,
Graeme