Re: [PATCH 0/7] net: Convert dev_set_mac_address() to struct sockaddr_storage
Kees Cook <[email protected]> Tue, 20 May 2025 17:42:32 -0700
| Newsgroups | org.kernel.vger.linux-wpan,org.infradead.lists.linux-nvme,org.kernel.vger.linux-hardening,org.kernel.vger.linux-hyperv,org.kernel.vger.linux-kernel,org.kernel.vger.linux-scsi,org.kernel.vger.linux-usb,org.kernel.vger.netdev,org.kernel.vger.target-devel |
|---|---|
| Message-ID | <202505201741.AFA146E7F6@keescook> |
On Tue, May 20, 2025 at 05:19:20PM -0700, Kuniyuki Iwashima wrote: > From: Kees Cook <[email protected]> > Date: Tue, 20 May 2025 15:30:59 -0700 > > Hi, > > > > As part of the effort to allow the compiler to reason about object sizes, > > we need to deal with the problematic variably sized struct sockaddr, > > which has no internal runtime size tracking. In much of the network > > stack the use of struct sockaddr_storage has been adopted. Continue the > > transition toward this for more of the internal APIs. Specifically: > > > > - inet_addr_is_any() > > - netif_set_mac_address() > > - dev_set_mac_address() > > > > Only 3 callers of dev_set_mac_address() needed adjustment; all others > > were already using struct sockaddr_storage internally. > > I guess dev_set_mac_address_user() was missed on the way ? > > For example, tap_ioctl() still uses sockaddr and calls > dev_set_mac_address_user(), which cast it to _storage. Ah yes, I can include that in the next version if you want? I was trying to find a stopping point since everything kind of touches everything ... :P -- Kees Cook