Cloudanix VulnDB

CVE-2026-98929

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux networking setup issue could produce warning messages when creating certain encrypted connections but does not allow unauthorized access.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Theoretical
Impact
Other
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Race condition during MACsec netdevice registration where SecY remains uninitialized before inetdev_init() triggers NETDEV_FEAT_CHANGE notifications, causing macsec_fill_info() to return -EMSGSIZE with zero key_len and emit uninitialized SCI values.

Why it matters to the business

Linux systems using MACsec offload may generate kernel warnings during encrypted link setup on LRO-capable interfaces with IPv4 forwarding enabled, increasing operational noise and complicating network troubleshooting in environments relying on stable device initialization.

How an attack unfolds

An attacker with sufficient privileges to create a MACsec device over a compatible lower device could trigger the registration ordering flaw to produce warnings or expose uninitialized attributes, though no public exploitation or threat actor activity is known.

How to fix it

Update the Linux kernel to a version containing the fix that initializes SecY and applies link attributes inside macsec_newlink() prior to registration, moves per-CPU stats allocation into ndo_init(), and handles partial allocation cleanup on failure.

How to confirm the fix worked

Verify updated kernel source or package version; create a test MACsec device over an LRO interface with IPv4 forwarding enabled and confirm absence of warnings in rtmsg_ifinfo_build_skb() or uninitialized SCI reports.

Typical attack path

  1. Obtain privileges to create MACsec netdevices
  2. Ensure lower device supports LRO and IPv4 forwarding is active
  3. Create MACsec device to invoke register_netdevice() before SecY initialization
  4. Observe resulting warning in rtmsg_ifinfo_build_skb()

How to detect it

Search kernel logs and dmesg for strings referencing rtmsg_ifinfo_build_skb warnings, macsec_fill_info returning EMSGSIZE, or uninitialized SCI values during netdevice registration events.

What your security team should do

  • Prioritize kernel updates for systems using MACsec offload
  • Review kernel logs for macsec-related warnings during device creation
  • Test MACsec configurations in staging before production rollout

The record

In the Linux kernel, the following vulnerability has been resolved: macsec: initialize SecY before registering the netdevice 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. Even without the warning, notifications during registration can report uninitialized SecY attributes, including the SCI. This ordering has existed since the driver was introduced. Initialize the SecY and apply the new-link attributes before registration. Move MAC address inheritance into macsec_newlink() so the SCI can also be initialized before registration-time notifications report it. Move the per-CPU statistics and metadata destination allocation into ndo_init(), and release partial allocations on failure.

Affected packages

Ecosystem Package Introduced Fixed