[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <202412171230.824B83D@keescook>
Date: Tue, 17 Dec 2024 12:30:36 -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 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.
--
Kees Cook
Powered by blists - more mailing lists