Control: reassign -1 udev 245-1 Control: retitle -1 udev: unitialised buffer used as interface altname Control: forwarded -1 https://github.com/systemd/systemd/issues/15232 Control: tags -1 patch upstream
On Mon, 2020-04-20 at 09:29 +0100, Marc Zyngier wrote:
> Hi all,
>
> I just managed to track this down to systemd-udev.
>
> While running the following command:
>
> ip link add link eth0 name macvtap0 type macvtap mode bridge
>
> I straced systemd-udev, and found the following nugget:
>
> [pid 637] sendto(15, {{len=48, type=0x6c /* RTM_??? */,
> flags=NLM_F_REQUEST|NLM_F_ACK|NLM_F_EXCL|NLM_F_CREATE|NLM_F_APPEND,
> seq=3, pid=0}, {family=AF_UNSPEC,
> "\x00\x00\x00\x07\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x10\x00\x34\x80\x0b\x00\x35\x00\x80\x40\x56\x07\xab\xaa\x00\x00"}},
> 48, 0, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 16) = 48
>
> where the undecoded RTM_??? is RTM_NEWLINKPROP, and the message
> containing:
>
> struct nlattr {
> nla_len = 16,
> nla_type = NLA_F_NESTED | IFLA_PROP_LIST,
> }
> struct ntattr {
> nla_len = 11,
> nla_type = IFLA_ALT_IFNAME,
> }
> altname = "\x80\x40\x56\x07\xab\xaa\x00\"
> padding = "\0x00"
>
> it looks like systemd-udev tries to set an altname (why?) based on some
> uninitialized structure, and the kernel happily honors the request.
>
> Based on the above, I'd say that iproute2 is innocent, and that someone
> should investigate systemd.
>
> Thanks,
>
> M.
You are indeed right, thanks for the analysis.
Upstream bug: https://github.com/systemd/systemd/issues/15232
Upstream fix: https://github.com/systemd/systemd/pull/15300
Introduced by:
https://github.com/systemd/systemd/commit/ef1d2c07f9567dfea8a4e012d8779a4ded2d9ae6
I'll leave it to the systemd maintainers to decide whether to backport
a fix or wait for a new release.
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
