Skip to main content

Linux CVE-2026-23103

MEDIUM
Improper Locking (CWE-667)
2026-02-04 416baaa9-dc9f-4396-8d5f-8c081fb06d67
5.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
SUSE
7.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Red Hat
4.7 MEDIUM
qualitative

Primary rating from NVD.

CVSS VectorNVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

5
Severity Changed
Jul 14, 2026 - 13:22 NVD
HIGH MEDIUM
CVSS changed
Jul 14, 2026 - 13:22 NVD
7.8 (HIGH) 5.5 (MEDIUM)
Patch released
Apr 09, 2026 - 20:30 nvd
Patch available
Analysis Generated
Mar 12, 2026 - 21:54 vuln.today
CVE Published
Feb 04, 2026 - 17:16 nvd
HIGH 7.8

DescriptionNVD

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.

  1. 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.

AnalysisAI

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.

Technical ContextAI

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 highl

RemediationAI

Monitor vendor advisories for a patch.

Vendor StatusVendor

SUSE

Severity: High
Product Status
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise Module for Basesystem 15 SP7 Affected
SUSE Linux Enterprise Server 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Server for SAP Applications 15 SP7 Affected

Share

CVE-2026-23103 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy