[PATCH net] macsec: initialize SecY before registering the netdevice

[PATCH net] macsec: initialize SecY before registering the netdevice

[Haseeb Malik via B4 Relay]

From: Haseeb Malik <haseebulhaq55@gmail.com>

Creating a MACsec device with MAC offload over an LRO-capable lower
device triggers a warning in rtmsg_ifinfo_build_skb() when IPv4
forwarding is enabled by default.

register_netdevice() invokes inetdev_init(), which disables LRO and emits
a NETDEV_FEAT_CHANGE notification. This reaches macsec_fill_info() before
macsec_add_dev() initializes the SecY. key_len is still zero, so
macsec_fill_info() returns -EMSGSIZE and trips the WARN_ON in
rtmsg_ifinfo_build_skb(), even though the skb has enough space.

Initialize the SecY and apply the new-link attributes before registration.
Move the per-CPU statistics and metadata destination allocation into
ndo_init(), and release partial allocations on failure. Keep SCI
assignment after registration because ndo_init() may inherit the lower
device's MAC address.

Fixes: ccfdec908922 ("macsec: Add support for GCM-AES-256 cipher suite")
Reported-by: syzbot+f2f6312ad1b5a0bfe316@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=f2f6312ad1b5a0bfe316
Suggested-by: Sabrina Dubroca <sd@queasysnail.net>
Link: https://lists.openwall.net/linux-kernel/2026/08/19/552
Assisted-by: LLM
Signed-off-by: Haseeb Malik <haseebulhaq55@gmail.com>
---
Tests:
  - arm64 KASAN/lockdep kernel build
  - original syzbot reproducer and reduced reproducer
  - 16 cipher/offload/forwarding combinations
  - link notifications, configuration error paths, and encrypted veth
    traffic
  - W=1 MACsec object builds with allmodconfig and allyesconfig
---
 drivers/net/macsec.c | 66 ++++++++++++++++++++++++++++------------------------
 1 file changed, 35 insertions(+), 31 deletions(-)

diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c
index 6f9f3aceffaa..11207d671fb6 100644
--- a/drivers/net/macsec.c
+++ b/drivers/net/macsec.c
@@ -3539,6 +3539,20 @@ static int macsec_dev_init(struct net_device *dev)
 	if (err)
 		return err;
 
+	err = -ENOMEM;
+	macsec->stats = netdev_alloc_pcpu_stats(struct pcpu_secy_stats);
+	if (!macsec->stats)
+		goto destroy_gro_cells;
+
+	macsec->secy.tx_sc.stats = netdev_alloc_pcpu_stats(struct pcpu_tx_sc_stats);
+	if (!macsec->secy.tx_sc.stats)
+		goto free_secy_stats;
+
+	macsec->secy.tx_sc.md_dst = metadata_dst_alloc(0, METADATA_MACSEC,
+						       GFP_KERNEL);
+	if (!macsec->secy.tx_sc.md_dst)
+		goto free_tx_sc_stats;
+
 	macsec_inherit_tso_max(dev);
 
 	dev->hw_features = real_dev->hw_features & MACSEC_OFFLOAD_FEATURES;
@@ -3560,6 +3574,14 @@ static int macsec_dev_init(struct net_device *dev)
 	netdev_hold(real_dev, &macsec->dev_tracker, GFP_KERNEL);
 
 	return 0;
+
+free_tx_sc_stats:
+	free_percpu(macsec->secy.tx_sc.stats);
+free_secy_stats:
+	free_percpu(macsec->stats);
+destroy_gro_cells:
+	gro_cells_destroy(&macsec->gro_cells);
+	return err;
 }
 
 static void macsec_dev_uninit(struct net_device *dev)
@@ -4116,29 +4138,11 @@ static sci_t dev_to_sci(struct net_device *dev, __be16 port)
 	return make_sci(dev->dev_addr, port);
 }
 
-static int macsec_add_dev(struct net_device *dev, sci_t sci, u8 icv_len)
+static void macsec_init_secy(struct net_device *dev, u8 icv_len)
 {
 	struct macsec_dev *macsec = macsec_priv(dev);
 	struct macsec_secy *secy = &macsec->secy;
 
-	macsec->stats = netdev_alloc_pcpu_stats(struct pcpu_secy_stats);
-	if (!macsec->stats)
-		return -ENOMEM;
-
-	secy->tx_sc.stats = netdev_alloc_pcpu_stats(struct pcpu_tx_sc_stats);
-	if (!secy->tx_sc.stats)
-		return -ENOMEM;
-
-	secy->tx_sc.md_dst = metadata_dst_alloc(0, METADATA_MACSEC, GFP_KERNEL);
-	if (!secy->tx_sc.md_dst)
-		/* macsec and secy percpu stats will be freed when unregistering
-		 * net_device in macsec_free_netdev()
-		 */
-		return -ENOMEM;
-
-	if (sci == MACSEC_UNDEF_SCI)
-		sci = dev_to_sci(dev, MACSEC_PORT_ES);
-
 	secy->netdev = dev;
 	secy->operational = true;
 	secy->key_len = DEFAULT_SAK_LEN;
@@ -4148,16 +4152,12 @@ static int macsec_add_dev(struct net_device *dev, sci_t sci, u8 icv_len)
 	secy->replay_protect = false;
 	secy->xpn = DEFAULT_XPN;
 
-	secy->sci = sci;
-	secy->tx_sc.md_dst->u.macsec_info.sci = sci;
 	secy->tx_sc.active = true;
 	secy->tx_sc.encoding_sa = DEFAULT_ENCODING_SA;
 	secy->tx_sc.encrypt = DEFAULT_ENCRYPT;
 	secy->tx_sc.send_sci = DEFAULT_SEND_SCI;
 	secy->tx_sc.end_station = false;
 	secy->tx_sc.scb = false;
-
-	return 0;
 }
 
 static struct lock_class_key macsec_netdev_addr_lock_key;
@@ -4220,6 +4220,14 @@ static int macsec_newlink(struct net_device *dev,
 	if (rx_handler && rx_handler != macsec_handle_frame)
 		return -EBUSY;
 
+	/* Registration can notify listeners before returning. */
+	macsec_init_secy(dev, icv_len);
+	if (data) {
+		err = macsec_changelink_common(dev, data);
+		if (err)
+			return err;
+	}
+
 	err = register_netdevice(dev);
 	if (err < 0)
 		return err;
@@ -4247,15 +4255,11 @@ static int macsec_newlink(struct net_device *dev,
 		goto unlink;
 	}
 
-	err = macsec_add_dev(dev, sci, icv_len);
-	if (err)
-		goto unlink;
+	if (sci == MACSEC_UNDEF_SCI)
+		sci = dev_to_sci(dev, MACSEC_PORT_ES);
 
-	if (data) {
-		err = macsec_changelink_common(dev, data);
-		if (err)
-			goto del_dev;
-	}
+	macsec->secy.sci = sci;
+	macsec->secy.tx_sc.md_dst->u.macsec_info.sci = sci;
 
 	/* If h/w offloading is available, propagate to the device */
 	if (macsec_is_offloaded(macsec)) {

---
base-commit: 78445023439506ebd83b86d40b1e428a3b309d4a
change-id: 20260911-fix-macsec-net-ff3bc5e7ab0a

Best regards,
-- 
Haseeb Malik <haseebulhaq55@gmail.com>

Re: [PATCH net] macsec: initialize SecY before registering the netdevice

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider:

Critical: 0 · High: 0 · Medium: 1 (2) · Low: 0

- [Medium] Incomplete fix: the registration-time RTM_NEWLINK notification
  that this patch makes succeed now carries a bogus IFLA_MACSEC_SCI = 0.

Pre-existing issues:
- [Medium] A user-supplied IFLA_MACSEC_SCI equal to MACSEC_UNDEF_SCI
  (0xffffffffffffffff) bypasses the duplicate-SCI check in…
- [Medium] In macsec_newlink(), once mdo_add_secy() has successfully
  programmed the offload engine (drivers/net/macsec.c:4264-4279), a…

--

macsec: initialize SecY before registering the netdevice

The patch moves SecY initialization and the new-link attribute handling
ahead of register_netdevice(), so that macsec_fill_info() does not fail
for notifications emitted during registration. The per-CPU stats and
metadata_dst allocations move into ndo_init() with an unwind path, and
the SCI assignment stays after registration.

Closes: https://syzkaller.appspot.com/bug?extid=f2f6312ad1b5a0bfe316
Link: https://lists.openwall.net/linux-kernel/2026/08/19/552

> diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c
> index 6f9f3aceffaad..11207d671fb6a 100644
> --- a/drivers/net/macsec.c
> +++ b/drivers/net/macsec.c

[ ... ]

> @@ -4116,29 +4138,11 @@ static sci_t dev_to_sci(struct net_device *dev, __be16 port)
>  	return make_sci(dev->dev_addr, port);
>  }
>
> -static int macsec_add_dev(struct net_device *dev, sci_t sci, u8 icv_len)
> +static void macsec_init_secy(struct net_device *dev, u8 icv_len)
>  {
>  	struct macsec_dev *macsec = macsec_priv(dev);
>  	struct macsec_secy *secy = &macsec->secy;
>
> -	macsec->stats = netdev_alloc_pcpu_stats(struct pcpu_secy_stats);
> -	if (!macsec->stats)
> -		return -ENOMEM;
> -
> -	secy->tx_sc.stats = netdev_alloc_pcpu_stats(struct pcpu_tx_sc_stats);
> -	if (!secy->tx_sc.stats)
> -		return -ENOMEM;
> -
> -	secy->tx_sc.md_dst = metadata_dst_alloc(0, METADATA_MACSEC, GFP_KERNEL);
> -	if (!secy->tx_sc.md_dst)
> -		/* macsec and secy percpu stats will be freed when unregistering
> -		 * net_device in macsec_free_netdev()
> -		 */
> -		return -ENOMEM;
> -
> -	if (sci == MACSEC_UNDEF_SCI)
> -		sci = dev_to_sci(dev, MACSEC_PORT_ES);
> -
>  	secy->netdev = dev;
>  	secy->operational = true;
>  	secy->key_len = DEFAULT_SAK_LEN;
> @@ -4148,16 +4152,12 @@ static int macsec_add_dev(struct net_device *dev, sci_t sci, u8 icv_len)
>  	secy->replay_protect = false;
>  	secy->xpn = DEFAULT_XPN;
>
> -	secy->sci = sci;
> -	secy->tx_sc.md_dst->u.macsec_info.sci = sci;
>  	secy->tx_sc.active = true;

[Severity: Medium]
With key_len set here but secy->sci left at zero until after registration,
what SCI does the notification that now succeeds actually carry?

macsec_fill_info() no longer hits the default case of the key_len switch,
so it reaches:

	if (nla_put_sci(skb, IFLA_MACSEC_SCI, secy->sci,
			IFLA_MACSEC_PAD) ||

while secy->sci is still the zero value of the freshly allocated private
area, i.e. MAC 00:00:00:00:00:00 with port 0. That is neither a value the
driver ever assigns nor MACSEC_UNDEF_SCI, and it contradicts an explicitly
requested IFLA_MACSEC_SCI as well as every later GET or dump for the same
ifindex.

The notification looks reachable on exactly the syzbot path:
register_netdevice() sets reg_state = NETREG_REGISTERED before
call_netdevice_notifiers(NETDEV_REGISTER), inetdev_init() calls
dev_disable_lro() which emits NETDEV_FEAT_CHANGE, and rtnetlink_event()
forwards that to rtmsg_ifinfo_event(), which only checks:

	if (dev->reg_state != NETREG_REGISTERED)
		return;

dev->rtnl_link_initializing only suppresses register_netdevice()'s own
rtmsg_ifinfo() and the DELLINK message, not this one. So RTNLGRP_LINK
listeners see an RTM_NEWLINK with IFLA_MACSEC_SCI = 0, and if macsec_newlink()
subsequently fails in netdev_upper_dev_link(), the sci_exists() -EBUSY case,
mdo_add_secy() or register_macsec_dev(), no DELLINK follows, so a monitor can
keep a phantom link with that SCI in its cache.

Could an explicitly requested SCI (IFLA_MACSEC_SCI or IFLA_MACSEC_PORT) be
programmed in macsec_init_secy() before registration? Only the
dev_to_sci(dev, MACSEC_PORT_ES) default depends on the MAC address inherited
by ndo_init(). If the ordering is intended to stay as is, could the commit
message mention that registration-time notifications now report SCI 0?

> @@ -4220,6 +4220,14 @@ static int macsec_newlink(struct net_device *dev,
>  	if (rx_handler && rx_handler != macsec_handle_frame)
>  		return -EBUSY;
>
> +	/* Registration can notify listeners before returning. */
> +	macsec_init_secy(dev, icv_len);
> +	if (data) {
> +		err = macsec_changelink_common(dev, data);
> +		if (err)
> +			return err;
> +	}
> +
>  	err = register_netdevice(dev);
>  	if (err < 0)
>  		return err;
> @@ -4247,15 +4255,11 @@ static int macsec_newlink(struct net_device *dev,
>  		goto unlink;
>  	}
>
> -	err = macsec_add_dev(dev, sci, icv_len);
> -	if (err)
> -		goto unlink;
> +	if (sci == MACSEC_UNDEF_SCI)
> +		sci = dev_to_sci(dev, MACSEC_PORT_ES);

[Severity: Medium]
This isn't a bug introduced by this patch, but while the two blocks are being
moved around, is the ordering of the MACSEC_UNDEF_SCI rewrite against the
duplicate check in macsec_newlink() intentional?

The uniqueness check runs on the raw attribute value:

	if (rx_handler && sci_exists(real_dev, sci)) {
		err = -EBUSY;
		goto unlink;
	}

	if (sci == MACSEC_UNDEF_SCI)
		sci = dev_to_sci(dev, MACSEC_PORT_ES);

sci_exists() only compares committed values:

	list_for_each_entry(macsec, &rxd->secys, secys) {
		if (macsec->secy.sci == sci)
			return true;
	}

No registered SecY can hold MACSEC_UNDEF_SCI, so passing
IFLA_MACSEC_SCI = 0xffffffffffffffff always passes the check, and the value
is then rewritten to dev_to_sci(dev, MACSEC_PORT_ES). Since
macsec_dev_init() inherits the lower device's MAC via eth_hw_addr_inherit(),
that default is normally the same SCI the first MACsec device on the same
lower device already uses, so two SecYs with identical secy.sci land in
rxd->secys and find_secy() always returns the first one. Would doing the
remap before the sci_exists() call, or rejecting MACSEC_UNDEF_SCI outright,
be preferable? The IFLA_MACSEC_SCI policy is a plain NLA_U64 with no value
validation.

>
> -	if (data) {
> -		err = macsec_changelink_common(dev, data);
> -		if (err)
> -			goto del_dev;
> -	}
> +	macsec->secy.sci = sci;
> +	macsec->secy.tx_sc.md_dst->u.macsec_info.sci = sci;
>
>  	/* If h/w offloading is available, propagate to the device */
>  	if (macsec_is_offloaded(macsec)) {

[Severity: Medium]
This is a pre-existing issue, but since the del_dev unwind path is being
touched here: after mdo_add_secy() has succeeded, does anything undo it when
register_macsec_dev() fails?

	err = macsec_offload(ops->mdo_add_secy, &ctx);
	...
	err = register_macsec_dev(real_dev, dev);
	if (err < 0)
		goto del_dev;

register_macsec_dev() can fail on the rxd allocation or in
netdev_rx_handler_register(). The del_dev label only calls macsec_del_dev(),
which is purely software (frees the rx_sc list and clears the tx SAs), then
netdev_upper_dev_unlink() and unregister_netdevice(). mdo_del_secy() is only
issued from macsec_common_dellink() and macsec_update_offload(), neither of
which runs on this path, and unregister_netdevice() only reaches
macsec_dev_uninit() (gro_cells_destroy).

For mlx5, mlx5e_macsec_add_secy() has already allocated a struct
mlx5e_macsec_device holding macdev = ctx->secy->netdev and consumed one of
the MLX5_MACSEC_NUM_OF_SUPPORTED_INTERFACES slots, so that entry keeps a
pointer to a device that is about to go away. PHY and MAC drivers that
program SecY registers in mdo_add_secy leave the hardware entry armed. Should
this path issue mdo_del_secy() before macsec_del_dev()?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260911-fix-macsec-net-v1-1-c82aa58ae741%40gmail.com