net card set VF and altname display blurred character

Bug #1933402 reported by Fred Kimmy
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
kunpeng920
Fix Released
Undecided
Unassigned
Ubuntu-20.04-hwe
Fix Released
Undecided
Unassigned
systemd (Ubuntu)
Fix Released
Undecided
Unassigned
Focal
Fix Released
Undecided
dann frazier
Groovy
Fix Released
Undecided
Unassigned
Hirsute
Fix Released
Undecided
Unassigned
Impish
Fix Released
Undecided
Unassigned

Bug Description

[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.

CVE References

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

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

Revision history for this message
dann frazier (dannf) wrote :

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.

Revision history for this message
Ike Panhc (ikepanhc) wrote :

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 �>���

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

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?

Revision history for this message
Ike Panhc (ikepanhc) wrote :

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

dann frazier (dannf)
Changed in systemd (Ubuntu Impish):
status: New → Fix Released
Changed in systemd (Ubuntu Hirsute):
status: New → Fix Released
Changed in systemd (Ubuntu Groovy):
status: New → Fix Released
description: updated
Changed in systemd (Ubuntu Focal):
status: New → In Progress
assignee: nobody → dann frazier (dannf)
Revision history for this message
Dan Streetman (ddstreet) wrote :

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)
description: updated
dann frazier (dannf)
Changed in systemd (Ubuntu Focal):
status: In Progress → Fix Committed
Revision history for this message
dann frazier (dannf) wrote : Re: [Bug 1933402] Re: net card set VF and altname display blurred character

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:

dann frazier (dannf)
Changed in kunpeng920:
status: New → Fix Committed
Revision history for this message
Brian Murray (brian-murray) wrote : Please test proposed package

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.

tags: added: verification-needed verification-needed-focal
Revision history for this message
Ubuntu SRU Bot (ubuntu-sru-bot) wrote : Autopkgtest regression report (systemd/245.4-4ubuntu3.8)

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!

Revision history for this message
dann frazier (dannf) wrote :

= 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

tags: added: verification-done verification-done-focal
removed: verification-needed verification-needed-focal
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in systemd (Ubuntu Focal):
status: Fix Committed → Fix Released
dann frazier (dannf)
Changed in kunpeng920:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.