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
This is a Linux kernel race condition in ipvlan address handling. A local authenticated user could potentially trigger inconsistent address state and kernel impact. The issue is rated high because the CVSS vector claims local, low-complexity exploitation with possible confidentiality, integrity, and availability impact.
Executive priority
Patch during the next high-priority kernel maintenance window, sooner for multi-tenant hosts, container infrastructure, or network appliances using ipvlan. No active exploitation is evidenced in the supplied sources, but local kernel-impact bugs can materially raise risk on shared systems.
Technical view
The ipvlan addrs_lock was per ipvlan device instead of per port. IPv6 address events can occur without RTNL locking, allowing concurrent address changes and races around address-busy checks and hash-table updates. Stable kernel commits move locking to the port and cover open/close paths.
Likely exposure
Exposure is most likely on Linux systems using ipvlan networking, especially where untrusted or lower-privileged local users can influence IPv6 address changes. Container hosts, network appliances, and products embedding Linux should validate kernel lineage and vendor advisories.
Exploitation context
The source bundle marks KEV as false and provides no evidence of active exploitation or public weaponization. Exploitation requires local privileges according to the CVSS vector. Treat exploitability details as incomplete beyond the race condition described by the kernel fix text.
Researcher notes
The root cause is lock scope mismatch: IPv6 paths can change addresses outside RTNL, while per-device addrs_lock permits concurrent per-port state mutation. The source calls it a minor, unlikely race, but CVSS assigns high impact. Version data in the bundle is incomplete; rely on vendor mapping.
Mitigation direction
Apply vendor-provided Linux kernel updates containing the referenced stable fixes.
Check distribution or appliance advisories for exact fixed package versions.
Prioritize systems using ipvlan or hosting untrusted local/container workloads.
Review Siemens SSA-019113 if Siemens products are in scope.
Validation and detection
Inventory kernels and appliances that use Linux ipvlan networking.
Compare running kernel builds against vendor fixed versions and referenced commits.
Check whether IPv6 address changes are used with ipvlan interfaces.
Confirm Siemens-affected assets against SSA-019113.
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.