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
