netdev - Re: [PATCH] net: rtnetlink: be more strict when setting MAC address

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20150817232316.GA20744@orbit.nwl.cc>
Date:	Tue, 18 Aug 2015 01:23:16 +0200
From:	Phil Sutter <phil@....cc>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org, tgraf@...g.ch,
	Stephen Hemminger <shemming@...cade.com>
Subject: Re: [PATCH] net: rtnetlink: be more strict when setting MAC address

On Mon, Aug 17, 2015 at 02:09:33PM -0700, David Miller wrote:
> From: Phil Sutter <phil@....cc>
> Date: Mon, 17 Aug 2015 23:06:47 +0200
> 
> > Upon evaluation of IFLA_ADDRESS and IFLA_BROADCAST messages, make sure
> > the passed argument length matches dev->addr_len exactly.
> > 
> > This fixes dubious behaviour of 'ip link set eth0 addr <MAC>' where
> > '<MAC>' is too long, e.g. '00:11:22:33:44:55:66:77'. Called like this,
> > 'ip' would return successfully and the kernel sets eth0's MAC address to
> > the leading six octets of the passed argument.
> > 
> > Signed-off-by: Phil Sutter <phil@....cc>
> 
> I don't think this behavior is very "dubious" and making the check more
> strict risks breaking things that have worked for a very long time.
> 
> I'm not applying this, sorry.

No problem. I was already afraid of this breaking something as commit
1840bb1, which introduces validate_linkmsg(), already mentions something
in that direction. Therefore I appreciate your feedback clarifying this
for me, although it is not quite the outcome I had wished for.

Seeing that the kernel checks the minimum length already, shifting the
maximum length check to kernel space felt like a natural choice.

Nevertheless, I think iproute2 should not behave this way. Stephen, do
you think it is reasonable to add a similar logic to iplink_parse() as
done in do_set() (i.e., finding out which is the correct length of LL
address for a given interface and validating input based on this)? If
so, is it appropriate to recycle get_address() function or should the
information come from netlink?

Thanks, Phil
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html