CVE-2026-23103: ipvlan: Make the addrs_lock be per port
In the Linux kernel, the following vulnerability has been resolved:
ipvlan: Make the addrs_lock be per port
Make the addrs_lock be per port, not per ipvlan dev.
Initial code seems to be written in the assumption,
that any address change must occur under RTNL.
But it is not so for the case of IPv6. So
1) Introduce per-port addrs_lock.
2) It was needed to fix places where it was forgotten
to take lock (ipvlan_open/ipvlan_close)
This appears to be a very minor problem though.
Since it's highly unlikely that ipvlan_add_addr() will
be called on 2 CPU simultaneously. But nevertheless,
this could cause:
1) False-negative of ipvlan_addr_busy(): one interface
iterated through all port->ipvlans + ipvlan->addrs
under some ipvlan spinlock, and another added IP
under its own lock. Though this is only possible
for IPv6, since looks like only ipvlan_addr6_event() can be
called without rtnl_lock.
2) Race since ipvlan_ht_addr_add(port) is called under
different ipvlan->addrs_lock locks
This should not affect performance, since add/remove IP
is a rare situation and spinlock is not taken on fast
paths.
Security readout for executives and security teams
Plain-English summary
A race condition in Linux ipvlan address management can occur when IPv6 addresses change concurrently on the same port. It could corrupt address-tracking state and potentially affect confidentiality, integrity, or availability. Exploitation requires local, low-privileged access, and the kernel description characterizes the triggering concurrency as highly unlikely.
Executive priority
Prioritize affected multi-tenant, container, or appliance environments where local users can influence ipvlan IPv6 configuration. Patch through normal high-severity kernel maintenance, escalating systems with untrusted local access. Immediate emergency action is not supported by the supplied exploitation evidence.
Technical view
The ipvlan driver previously protected address lists with locks scoped to individual ipvlan devices. IPv6 address notifications can occur without the RTNL lock, allowing operations on one port under different locks. This can produce a false-negative address-conflict check or race during hash insertion. The correction introduces a per-port address lock and covers previously unlocked open and close paths.
Likely exposure
Exposure is limited to affected Linux kernels using ipvlan, particularly where IPv6 addresses may be added concurrently across ipvlan interfaces sharing a port. The supplied version data is ambiguous and includes commit identifiers, so distribution-specific kernel and backport status must be verified rather than inferred from version numbers alone.
Exploitation context
The supplied CVSS score is 7.8 and requires local access with low privileges, without user interaction. The record is not in KEV, and the supplied sources provide no evidence of exploitation in the wild or a public exploit. The described race is considered highly unlikely by the kernel fix description.
Researcher notes
The plausible trigger is concurrent IPv6 address-list mutation because that notification path may run without RTNL serialization. Investigate false-negative address-busy checks and concurrent address-hash insertion. The CVSS impact is high, but the upstream description calls the race minor and unlikely; no CWE, crash evidence, exploit evidence, or precise distribution mapping is supplied.
Mitigation direction
Install a vendor-supported kernel containing the per-port ipvlan address-locking fix.
Check Linux distribution and appliance advisories for backport status before relying on kernel version numbers.
Where updating is delayed, reduce unnecessary ipvlan and IPv6 use after assessing operational impact.
Review the Siemens advisory if potentially relevant Siemens products are deployed.
Validation and detection
Inventory Linux hosts and appliances using ipvlan interfaces.
Determine whether IPv6 address changes can occur on ipvlan interfaces sharing one port.
Compare each kernel build against vendor advisories and the referenced stable commits.
After updating, confirm the installed kernel package includes the ipvlan locking correction.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-23103 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
2ADP providers
9Source links
SSVC decision data
CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: noTechnical Impact: total
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.