net card set VF and altname display blurred character

[Fred Kimmy]

[Impact]
When running with the HWE kernel (5.4 didn't support altnames), altnames containing garbage (uninitialized memory) may get assigned to a NIC. This is 100% reproducible on arm64. The upstream commit message suggests that this has been seen to cause segfaults.

[Test Case]
1) echo 1 > /sys/class/net/enp189s0f0/device/sriov_numvfs
2) ip a
3)
10: eno1v0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 1e:d8:e1:e9:ae:25 brd ff:ff:ff:ff:ff:ff
    altname @▒ު▒
    altname enp125s0f0v0
11: enp189s0f0v0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 76:ea:f4:65:dd:33 brd ff:ff:ff:ff:ff:ff
    altname ▒b▒ު▒
    altname ▒▒▒▒▒▒

[Fix]
There's a one liner upstream fix that simply initializes a variable:
https://github.com/systemd/systemd/commit/61fd7d6720c562c88ab79062ff8d131e5e3c7b1b

[What Could Go Wrong]
The fix itself is innocuous - just initializing a variable to NULL. So the real risk here would seem to be limited to the common risks in updating a core package in the Ubuntu distribution.

[Christian Ehrhardt  (paelzer)]

Hi,
since this is some character/encoding mess it would be helpful to get hat value those have exactly.
I mean there might be a byte swap or odd encoding somewhere, but these values might help to track down what it is.

here an example from a non-affected system (for comparison):

$ ip a | grep altname | hexdump --canonical
00000000 20 20 20 20 61 6c 74 6e 61 6d 65 20 65 6e 70 32 | altname enp2|
00000010 73 30 66 30 0a 20 20 20 20 61 6c 74 6e 61 6d 65 |s0f0. altname|
00000020 20 65 6e 70 32 73 30 66 31 0a 20 20 20 20 61 6c | enp2s0f1. al|
00000030 74 6e 61 6d 65 20 65 6e 70 32 73 30 66 32 0a 20 |tname enp2s0f2. |
00000040 20 20 20 61 6c 74 6e 61 6d 65 20 65 6e 70 32 73 | altname enp2s|
00000050 30 66 33 0a 20 20 20 20 61 6c 74 6e 61 6d 65 20 |0f3. altname |
00000060 65 6e 70 34 73 30 66 30 0a 20 20 20 20 61 6c 74 |enp4s0f0. alt|
00000070 6e 61 6d 65 20 65 6e 70 38 73 30 6e 70 30 0a 20 |name enp8s0np0. |
00000080 20 20 20 61 6c 74 6e 61 6d 65 20 65 6e 70 34 73 | altname enp4s|
00000090 30 66 31 0a |0f1.|
00000094

[dann frazier (dannf)]

I happened to be on a system displaying this issue, so here ya go:

$ ip address show dev eno1v0 | grep --binary-file=text altname
    altname P�
              ���
    altname enp125s0f0v0
$ ip address show dev eno1v0 | grep --binary-file=text altname | hexdump -C
00000000 20 20 20 20 61 6c 74 6e 61 6d 65 20 50 89 0b f6 | altname P...|
00000010 aa aa 0a 20 20 20 20 61 6c 74 6e 61 6d 65 20 65 |... altname e|
00000020 6e 70 31 32 35 73 30 66 30 76 30 0a |np125s0f0v0.|
0000002c

Sorry, I haven't had time to try and look for a pattern there myself.

$ cat /proc/version
Linux version 5.8.0-59-generic (buildd@bos02-arm64-044) (gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #66~20.04.1-Ubuntu SMP Thu Jun 17 11:13:01 UTC 2021

Also tried latest iproute2-next branch (@3e26254) just in case it is a userspace issue (unlikely given Christian's "good" example), and verified it is still an issue.

[Ike Panhc (ikepanhc)]

I can't find pattern yet but easy to reproduce.

ubuntu@kreiken:/sys/class/net/enp189s0f0/device$ ip a | grep -a altname | hexdump -C
00000000 20 20 20 20 61 6c 74 6e 61 6d 65 20 65 6e 70 31 | altname enp1|
00000010 32 35 73 30 66 30 0a 20 20 20 20 61 6c 74 6e 61 |25s0f0. altna|
00000020 6d 65 20 65 6e 70 31 32 35 73 30 66 31 0a 20 20 |me enp125s0f1. |
00000030 20 20 61 6c 74 6e 61 6d 65 20 65 6e 70 31 32 35 | altname enp125|
00000040 73 30 66 32 0a 20 20 20 20 61 6c 74 6e 61 6d 65 |s0f2. altname|
00000050 20 65 6e 70 31 32 35 73 30 66 33 0a 20 20 20 20 | enp125s0f3. |
00000060 61 6c 74 6e 61 6d 65 20 a0 46 17 07 ab aa 0a 20 |altname .F..... |
00000070 20 20 20 61 6c 74 6e 61 6d 65 20 b0 3e e3 a4 ff | altname .>...|
00000080 ff 0a |..|
00000082
ubuntu@kreiken:/sys/class/net/enp189s0f0/device$ ip a | grep -a altname
    altname enp125s0f0
    altname enp125s0f1
    altname enp125s0f2
    altname enp125s0f3
    altname �F��
    altname �>���

[Christian Ehrhardt  (paelzer)]

Hmm,
to further corner the failing code.
1. is this failing in e.g. json output as well?
 $ ip -j -p a | grep altname
2. if you set an additional altname is it ok?
 $ sudo ip link property add dev enp2s0f0 altname mytest
 $ ip a | grep altname
3. try more names
  $ sudo apt install netsniff-ng
  # Depends on your kernel headers
  $ sudo /usr/bin/bash -x /usr/src/linux-headers-5.11.0-22/tools/testing/selftests/net/altnames.sh

If #2 & #3 didn't fail we need to find who adds these bad altnames and how it does so.
I haven't found a good interface to cross check, systemd/udev seems to do that.
So it might come down to debugging systemd/udev while hot-plugging one of those devices?

[Ike Panhc (ikepanhc)]

This issue can only be reproduced with 5.8 kernel since altname is introduced since 5.5 kernel

[Dan Streetman (ddstreet)]

systemd doesn't use iproute2 tooling to set the altnames, it sets them directly with netlink.

what's the output from udevadm info for one of the affected interfaces? e.g.

$ udevadm info /sys/class/net/eno1v0

[dann frazier (dannf)]

On Mon, Jun 28, 2021 at 10:28:00PM -0000, Dan Streetman wrote:
> systemd doesn't use iproute2 tooling to set the altnames, it sets them
> directly with netlink.

You're right. The problem is that it does so w/ possibly uninitialized
memory. I added the following patch to demonstrate:

--- systemd-245.4.orig/src/udev/net/link-config.c
+++ systemd-245.4/src/udev/net/link-config.c
@@ -530,6 +530,7 @@ int link_config_apply(link_config_ctx *c
                                 assert_not_reached("invalid policy");
                         }
                         if (!isempty(n)) {
+ log_debug("DANNF: adding altname %s", n);
                                 r = strv_extend(&altnames, n);
                                 if (r < 0)
                                         return log_oom();

Which logs the following:
DANNF: adding altname ��
DANNF: adding altname ��'���
DANNF: adding altname ��'���
DANNF: adding altname enp7s0v0

Which is because we never enter the preceding switch statement.

> what's the output from udevadm info for one of the affected interfaces?
> e.g.
>
> $ udevadm info /sys/class/net/eno1v0

Here's the output from the interface with which I'm reproducing:

$ sudo udevadm info /sys/class/net/enp7s0v0
P: /devices/pci0000:00/0000:00:0c.0/0000:04:00.0/0000:05:01.0/0000:07:00.1/net/enp7s0v0
L: 0
E: DEVPATH=/devices/pci0000:00/0000:00:0c.0/0000:04:00.0/0000:05:01.0/0000:07:00.1/net/enp7s0v0
E: INTERFACE=enp7s0v0
E: IFINDEX=19
E: SUBSYSTEM=net
E: USEC_INITIALIZED=59449992522
E: ID_MM_CANDIDATE=1
E: ID_NET_NAMING_SCHEME=v245
E: ID_NET_NAME_PATH=enp7s0v0
E: ID_BUS=pci
E: ID_VENDOR_ID=0x19e5
E: ID_MODEL_ID=0x375e
E: ID_PCI_CLASS_FROM_DATABASE=Network controller
E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller
E: ID_VENDOR_FROM_DATABASE=Huawei Technologies Co., Ltd.
E: ID_MODEL_FROM_DATABASE=Hi1822 Family Virtual Function
E: ID_PATH=pci-0000:07:00.1
E: ID_PATH_TAG=pci-0000_07_00_1
E: ID_NET_DRIVER=hinic
E: ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link
E: ID_NET_NAME=enp7s0v0
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/enp7s0v0 /sys/subsystem/net/devices/enp7s0v0
E: TAGS=:systemd:

[Brian Murray (brian-murray)]

Hello Fred, or anyone else affected,

Accepted systemd into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/245.4-4ubuntu3.8 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted systemd (245.4-4ubuntu3.8) for focal have finished running.
The following regressions have been reported in tests triggered by the package:

asterisk/1:16.2.1~dfsg-2ubuntu1 (armhf)
gvfs/1.44.1-1ubuntu1 (amd64)
linux-oem-5.6/5.6.0-1057.61 (amd64)
munin/2.0.56-1ubuntu1 (ppc64el)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[dann frazier (dannf)]

= Verification =
Before:
14: enp1s0f0np0v0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 92:aa:d8:f1:ae:10 brd ff:ff:ff:ff:ff:ff
    altname `�lժ�
    altname ��lժ�

After:
15: enp1s0f0np0v0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 92:aa:d8:f1:ae:10 brd ff:ff:ff:ff:ff:f

ubuntu@d06-3:~$ dpkg-query -W systemd
systemd 245.4-4ubuntu3.8

[Launchpad Janitor (janitor)]

This bug was fixed in the package systemd - 245.4-4ubuntu3.10

---------------
systemd (245.4-4ubuntu3.10) focal-security; urgency=medium

  * SECURITY UPDATE: DoS via DHCP FORCERENEW
    - debian/patches/CVE-2020-13529.patch: tentatively ignore FORCERENEW
      command in src/libsystemd-network/sd-dhcp-client.c.
    - CVE-2020-13529
  * SECURITY UPDATE: denial of service via stack exhaustion
    - debian/patches/CVE-2021-33910.patch: do not use strdupa() on a path
      in src/basic/unit-name.c.
    - CVE-2021-33910

 -- Marc Deslauriers <email address hidden> Tue, 20 Jul 2021 07:39:51 -0400