linux-kernel - Re: [PATCH] net: core: dev.c confirmed to use classic sockaddr

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: <202412172155.F01961439@keescook>
Date: Tue, 17 Dec 2024 21:58:43 -0800
From: Kees Cook <kees@...nel.org>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: "David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	netdev@...r.kernel.org, Simon Horman <horms@...nel.org>,
	David Ahern <dsahern@...nel.org>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	Lorenzo Bianconi <lorenzo@...nel.org>,
	Joe Damato <jdamato@...tly.com>,
	Alexander Lobakin <aleksander.lobakin@...el.com>,
	linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org
Subject: Re: [PATCH] net: core: dev.c confirmed to use classic sockaddr

On Tue, Dec 17, 2024 at 12:30:36PM -0800, Kees Cook wrote:
> On Tue, Dec 17, 2024 at 10:35:44AM -0500, Willem de Bruijn wrote:
> > Kees Cook wrote:
> > > As part of trying to clean up struct sock_addr, add comments about the
> > > sockaddr arguments of dev_[gs]et_mac_address() being actual classic "max
> > > 14 bytes in sa_data" sockaddr instances and not struct sockaddr_storage.
> > 
> > What is this assertion based on?
> > 
> > I see various non-Ethernet .ndo_set_mac_address implementations, which
> > dev_set_mac_address calls. And dev_set_mac_addr_user is called from
> > rtnetlink do_setlink. Which kmalloc's sa based on dev->addr_len.
> 
> Yeah, I was clearly missing several cases. Please ignore this patch. I
> will re-examine this.

So, I think I see what happened -- I missed the dev->addr_len in
dev_set_mac_address(), and saw that dev_get_mac_address() caps the
address to 14:

        size_t size = sizeof(sa->sa_data_min);
...
        if (!dev->addr_len)
                memset(sa->sa_data, 0, size);
        else
                memcpy(sa->sa_data, dev->dev_addr,
                       min_t(size_t, size, dev->addr_len));

It seems only tun/tap and SIOCGIFHWADDR use the "get" interface, though.

-- 
Kees Cook