From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
To: Kees Cook <kees@kernel.org>, Kuniyuki Iwashima <kuniyu@amazon.com>
Cc: Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
Ido Schimmel <idosch@nvidia.com>,
netdev@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
Sagi Grimberg <sagi@grimberg.me>,
Chaitanya Kulkarni <kch@nvidia.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Mike Christie <michael.christie@oracle.com>,
Max Gurtovoy <mgurtovoy@nvidia.com>,
Maurizio Lombardi <mlombard@redhat.com>,
Dmitry Bogdanov <d.bogdanov@yadro.com>,
Mingzhe Zou <mingzhe.zou@easystack.cn>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
"Dr. David Alan Gilbert" <linux@treblig.org>,
Andrew Lunn <andrew+netdev@lunn.ch>,
Stanislav Fomichev <sdf@fomichev.me>,
Cosmin Ratiu <cratiu@nvidia.com>, Lei Yang <leiyang@redhat.com>,
Samuel Mendoza-Jonas <sam@mendozajonas.com>,
Paul Fertser <fercerpav@gmail.com>,
Alexander Aring <alex.aring@gmail.com>,
Stefan Schmidt <stefan@datenfreihafen.org>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Hayes Wang <hayeswang@realtek.com>,
Douglas Anderson <dianders@chromium.org>,
Grant Grundler <grundler@chromium.org>,
Jay Vosburgh <jv@jvosburgh.net>,
"K. Y. Srinivasan" <kys@microsoft.com>,
Haiyang Zhang <haiyangz@microsoft.com>,
Wei Liu <wei.liu@kernel.org>, Dexuan Cui <decui@microsoft.com>,
Jiri Pirko <jiri@resnulli.us>, Eric Biggers <ebiggers@google.com>,
Milan Broz <gmazyland@gmail.com>, Philipp Hahn <phahn-oss@avm.de>,
Ard Biesheuvel <ardb@kernel.org>,
Al Viro <viro@zeniv.linux.org.uk>,
Ahmed Zaki <ahmed.zaki@intel.com>,
Alexander Lobakin <aleksander.lobakin@intel.com>,
Xiao Liang <shaw.leon@gmail.com>,
linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org,
linux-scsi@vger.kernel.org, target-devel@vger.kernel.org,
linux-wpan@vger.kernel.org, linux-usb@vger.kernel.org,
linux-hyperv@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH 7/7] rtnetlink: do_setlink: Use struct sockaddr_storage
Date: Tue, 20 May 2025 16:50:29 -0600 [thread overview]
Message-ID: <2af2857c-d4b9-45c1-b241-dffa23ff4f32@embeddedor.com> (raw)
In-Reply-To: <20250520223108.2672023-7-kees@kernel.org>
On 20/05/25 16:31, Kees Cook wrote:
> Instead of a heap allocating a variably sized struct sockaddr and lying
> about the type in the call to netif_set_mac_address(), use a stack
> allocated struct sockaddr_storage. This lets us drop the cast and avoid
> the allocation.
>
> Putting "ss" on the stack means it will get a reused stack slot since
> it is the same size (128B) as other existing single-scope stack variables,
> like the vfinfo array (128B), so no additional stack space is used by
> this function.
>
> Signed-off-by: Kees Cook <kees@kernel.org>
Acked-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Thanks!
-Gustavo
> ---
> Cc: Kuniyuki Iwashima <kuniyu@amazon.com>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Paolo Abeni <pabeni@redhat.com>
> Cc: Simon Horman <horms@kernel.org>
> Cc: Ido Schimmel <idosch@nvidia.com>
> Cc: <netdev@vger.kernel.org>
> ---
> net/core/rtnetlink.c | 19 ++++---------------
> 1 file changed, 4 insertions(+), 15 deletions(-)
>
> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> index 9743f1c2ae3c..f9a35bdc58ad 100644
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -3080,17 +3080,7 @@ static int do_setlink(const struct sk_buff *skb, struct net_device *dev,
> }
>
> if (tb[IFLA_ADDRESS]) {
> - struct sockaddr *sa;
> - int len;
> -
> - len = sizeof(sa_family_t) + max_t(size_t, dev->addr_len,
> - sizeof(*sa));
> - sa = kmalloc(len, GFP_KERNEL);
> - if (!sa) {
> - err = -ENOMEM;
> - goto errout;
> - }
> - sa->sa_family = dev->type;
> + struct sockaddr_storage ss = { };
>
> netdev_unlock_ops(dev);
>
> @@ -3098,10 +3088,9 @@ static int do_setlink(const struct sk_buff *skb, struct net_device *dev,
> down_write(&dev_addr_sem);
> netdev_lock_ops(dev);
>
> - memcpy(sa->sa_data, nla_data(tb[IFLA_ADDRESS]),
> - dev->addr_len);
> - err = netif_set_mac_address(dev, (struct sockaddr_storage *)sa, extack);
> - kfree(sa);
> + ss.ss_family = dev->type;
> + memcpy(ss.__data, nla_data(tb[IFLA_ADDRESS]), dev->addr_len);
> + err = netif_set_mac_address(dev, &ss, extack);
> if (err) {
> up_write(&dev_addr_sem);
> goto errout;
next prev parent reply other threads:[~2025-05-20 23:46 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-20 22:30 [PATCH 0/7] net: Convert dev_set_mac_address() to struct sockaddr_storage Kees Cook
2025-05-20 22:31 ` [PATCH 1/7] net: core: Convert inet_addr_is_any() to sockaddr_storage Kees Cook
2025-05-21 0:04 ` Kuniyuki Iwashima
2025-05-21 1:26 ` Martin K. Petersen
2025-05-20 22:31 ` [PATCH 2/7] net: core: Switch netif_set_mac_address() to struct sockaddr_storage Kees Cook
2025-05-20 22:47 ` Gustavo A. R. Silva
2025-05-20 22:31 ` [PATCH 3/7] net/ncsi: Use struct sockaddr_storage for pending_mac Kees Cook
2025-05-20 22:48 ` Gustavo A. R. Silva
2025-05-20 22:31 ` [PATCH 4/7] ieee802154: Use struct sockaddr_storage with dev_set_mac_address() Kees Cook
2025-05-20 22:49 ` Gustavo A. R. Silva
2025-05-20 22:31 ` [PATCH 5/7] net: usb: r8152: Convert to use struct sockaddr_storage internally Kees Cook
2025-05-20 22:49 ` Gustavo A. R. Silva
2025-05-20 22:31 ` [PATCH 6/7] net: core: Convert dev_set_mac_address() to struct sockaddr_storage Kees Cook
2025-05-20 22:50 ` Gustavo A. R. Silva
2025-05-20 22:31 ` [PATCH 7/7] rtnetlink: do_setlink: Use " Kees Cook
2025-05-20 22:50 ` Gustavo A. R. Silva [this message]
2025-05-21 0:19 ` [PATCH 0/7] net: Convert dev_set_mac_address() to " Kuniyuki Iwashima
2025-05-21 0:42 ` Kees Cook
2025-05-21 3:09 ` Jakub Kicinski
2025-05-21 5:18 ` Kees Cook
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2af2857c-d4b9-45c1-b241-dffa23ff4f32@embeddedor.com \
--to=gustavo@embeddedor.com \
--cc=ahmed.zaki@intel.com \
--cc=aleksander.lobakin@intel.com \
--cc=alex.aring@gmail.com \
--cc=andrew+netdev@lunn.ch \
--cc=ardb@kernel.org \
--cc=christophe.leroy@csgroup.eu \
--cc=cratiu@nvidia.com \
--cc=d.bogdanov@yadro.com \
--cc=davem@davemloft.net \
--cc=decui@microsoft.com \
--cc=dianders@chromium.org \
--cc=ebiggers@google.com \
--cc=edumazet@google.com \
--cc=fercerpav@gmail.com \
--cc=gmazyland@gmail.com \
--cc=grundler@chromium.org \
--cc=haiyangz@microsoft.com \
--cc=hayeswang@realtek.com \
--cc=hch@lst.de \
--cc=horms@kernel.org \
--cc=idosch@nvidia.com \
--cc=jiri@resnulli.us \
--cc=jv@jvosburgh.net \
--cc=kch@nvidia.com \
--cc=kees@kernel.org \
--cc=kuba@kernel.org \
--cc=kuniyu@amazon.com \
--cc=kys@microsoft.com \
--cc=leiyang@redhat.com \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=linux-wpan@vger.kernel.org \
--cc=linux@treblig.org \
--cc=martin.petersen@oracle.com \
--cc=mgurtovoy@nvidia.com \
--cc=michael.christie@oracle.com \
--cc=mingzhe.zou@easystack.cn \
--cc=miquel.raynal@bootlin.com \
--cc=mlombard@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=phahn-oss@avm.de \
--cc=sagi@grimberg.me \
--cc=sam@mendozajonas.com \
--cc=sdf@fomichev.me \
--cc=shaw.leon@gmail.com \
--cc=stefan@datenfreihafen.org \
--cc=target-devel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=wei.liu@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox