Skip to main content

Linux Kernel EUVDEUVD-2026-86726

| CVE-2026-98073 HIGH
2026-09-25 Linux GHSA-g33p-j5vg-7cwx
High
Disputed · 7.8 Vendor: Linux
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Obtain local CAP_NET_ADMIN via user namespace
  2. Delivery
    Create netdevs in root and non-root netns
  3. Exploit
    Assign identical altname to both
  4. Execution
    Destroy non-root netns triggering cleanup_net
  5. Persist
    altname conflict trips WARN_ON in cfg80211_pernet_exit
  6. Impact
    Kernel warning splat (panic under panic_on_warn)

Vulnerability Assessment

Exploitation Conditions

Requires local ability to create network namespaces and network devices and to assign a duplicate alternative name (altname) across the root netns and a non-root netns, then destroy the non-root netns - i.e. CAP_NET_ADMIN in the relevant netns, obtainable by an unprivileged user where unprivileged user namespaces are enabled. The vulnerable warning path is in the wireless subsystems, so CONFIG_CFG80211 and/or CONFIG_CFG802154 must be built in. Practical impact is limited: on default kernels it produces only a WARN_ON splat, becoming a genuine crash/DoS only on kernels configured with panic_on_warn=1. No remote or network-facing vector exists.

Impact

This is a low-real-risk issue whose input CVSS (7.8 HIGH, AV:L/AC:L/PR:L/C:H/I:H/A:H) is materially overstated. The actual defect is a WARN_ON splat: the fix in __dev_change_net_namespace() removes conflicting altnames for a dying netns so that cfg80211_pernet_exit()/cfg802154_pernet_exit() no longer trigger the warning at net/wireless/core.c:1871 during cleanup_net. There is no memory corruption, no use-after-free, and no data leakage described - the C:H/I:H/A:H claim is not supported by the text. The only availability consequence is a kernel panic on hosts configured with panic_on_warn=1 (as syzbot itself runs); on default kernels it is a benign warning splat plus a leaked altname-conflict state. No EPSS score, no CISA KEV listing, and no POC/exploit field is set in the input, so there is no evidence of exploitation or automatability; however, the advisory itself describes a deterministic syzbot reproducer, so triggering is trivial once local access exists. The AV:L/PR:L portion of the vector is consistent with the description (local, privileged network operations). Net: treat as a routine kernel hardening/DoS-hygiene fix, not a priority patch, unless you run panic_on_warn in production.

Exploit ScenarioDerived

A local user who can create network namespaces and network devices (via CAP_NET_ADMIN, reachable through unprivileged user namespaces on many distros) creates two netdevs, assigns them the same alternative name across the root and a non-root netns, then destroys the non-root netns. During cleanup_net the wireless pernet exit path forces the device back to init_net, hits the altname conflict, and trips WARN_ON - which on a panic_on_warn kernel becomes a denial of service. The advisory describes a working syzbot reproducer, though no weaponized public exploit is indicated in the input signals.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
No patch listed yet 0.2% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Sep 25, 2026

A local altname-conflict handling flaw in the Linux kernel's network namespace teardown path (__dev_change_net_namespace()) allows an attacker with CAP_NET_ADMIN in a network namespace to trigger a WARN_ON assertion splat in cfg80211_pernet_exit() by assigning the same alternative interface name to devices in both the root netns and a non-root netns and then destroying the non-root netns. The affected code is the wireless (cfg80211/cfg802154) per-netns cleanup, which previously lacked the conflict-removal logic already added for default_device_exit_net(); the fix generalizes that cleanup into __dev_change_net_namespace(). Exploitation requires local access and the ability to create network namespaces and devices - achievable by an unprivileged user where unprivileged user namespaces are enabled - but the practical impact is limited to a kernel warning on default configurations, escalating to a real denial of service only when panic_on_warn=1 is set; no public exploit code has been identified at time of analysis, and this issue is not confirmed actively exploited (CISA KEV). Our independent assessment rates this as low real risk and considers the supplied CVSS 7.8 (C:H/I:H/A:H) materially overstated.

RemediationAI

Vendor-released patch: Linux 6.18.53, Linux 7.2.7, and Linux 7.3-rc2 incorporate the fix, distributed as stable commits ac6631843269e6a9b2164e393b7f729328711d78, debac3a20dec524a59625cf10fa2f18571127824, and a29ea5b5034654aaaa4aadd771f48c01abfd2dfa (see https://git.kernel.org/stable/c/ac6631843269e6a9b2164e393b7f729328711d78, https://git.kernel.org/stable/c/debac3a20dec524a59625cf10fa2f18571127824, https://git.kernel.org/stable/c/a29ea5b5034654aaaa4aadd771f48c01abfd2dfa); upgrade to the matching stable release for your branch or cherry-pick the relevant commit, and reboot since the change is in core network code. Because the defect merely produces a WARN_ON on ordinary kernels, the highest-value compensating control is to confirm panic_on_warn=0 (the default) on production hosts, since with panic_on_warn=1 the warning becomes a full denial of service - note this does not fix the underlying invariant bug and reduces crash-capture granularity elsewhere. Additionally, restrict the attack prerequisite by disabling unprivileged user namespaces (kernel.unprivileged_userns_clone=0 or user.max_user_namespaces=0), which prevents unprivileged local users from obtaining CAP_NET_ADMIN in a child netns but will break rootless containers, bwrap/Flatpak-style sandboxes, and some CI tooling. Where unprivileged user namespaces cannot be disabled, apply seccomp/LSM policy to block unshare(CLONE_NEWNET) and nl80211/rtnetlink altname operations for untrusted local users, accepting that this also limits legitimate network-namespace workloads. Disabling CONFIG_CFG80211/CONFIG_CFG802154 removes the vulnerable exit path entirely but is only viable for kernels on systems with no wireless hardware or wireless-stack dependency.

Affected VersionsENISA

Linux 36fbf1e52bd3ff8a5cb604955eedfc9350c2e6cc <ac6631843269e6a9b2164e393b7f729328711d78
Linux patch: 6.18.53
Linux patch: 0
Linux patch: 7.2.7
Linux 5.5
Linux 36fbf1e52bd3ff8a5cb604955eedfc9350c2e6cc <debac3a20dec524a59625cf10fa2f18571127824
Linux 36fbf1e52bd3ff8a5cb604955eedfc9350c2e6cc <a29ea5b5034654aaaa4aadd771f48c01abfd2dfa
Linux patch: 7.3-rc2

Affected Packages

euvd linux no fix

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

The Linux kernel network stack lets each net_device carry alternative names (altnames) in addition to its primary ifname, and commit 7663d522099e introduced a check that rejects moving a device into a namespace when an altname conflict already exists there. The wireless per-namespace exit hooks cfg80211_pernet_exit() and cfg802154_pernet_exit() call cfg80211_switch_netns()/cfg802154_switch_netns() to migrate wireless devices back to init_net during netns teardown, and these calls fail when init_net already contains a device bearing the same altname - a situation that is trivially arranged by creating one device in the root netns and another in a child netns with an identical altname. The identical problem in default_device_exit_net() was previously patched by d09486a04f5d, which removed conflicting altnames from devices belonging to the dying namespace; the present fix generalizes that behavior by performing the conflicting-altname removal directly inside __dev_change_net_namespace(), so all namespace-move paths (wireless included) are covered. Root cause is improper handling of an altname uniqueness invariant during namespace migration - the kernel hits a WARN_ON rather than dereferencing corrupt state, which is why the real-world outcome is an assertion splat and not memory corruption. Exposure requires CONFIG_CFG80211 and/or CONFIG_CFG802154 to be built into the kernel, and the CPE data (cpe:2.3:a:linux:linux) indicates the upstream Linux kernel tree across affected stable branches. The supplied CWE field is empty, so no specific CWE class should be asserted; the behavioral class is a broken-invariant/assertion failure in namespace teardown logic.

Know when the next one hits your stack

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Sources disagree (Low–High)
Vendor (Linux) PRIMARY 7.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
vuln.today AI 3.3 LOW

Local privileged netns/altname operations (AV:L, PR:L) with a deterministic repro (AC:L); only a WARN splat with no confidentiality/integrity impact and availability loss (A:L) limited to panic_on_warn kernels.

3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
SUSE 5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Red Hat 5.5 LOW

vuln.today treats the vendor’s rating as authoritative. A higher third-party CVSS (e.g. CISA-ADP) is shown for transparency but does not drive the headline severity.

CVSS VectorVendor: Linux

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

3
CVSS changed
Sep 25, 2026 - 15:22 NVD
7.8 (HIGH)
CVE Published
Sep 25, 2026 - 10:24 cve.org
HIGH 7.8
CVE Published
Sep 25, 2026 - 10:24 cve.org
UNKNOWN (no severity yet)

DescriptionCVE.org

In the Linux kernel, the following vulnerability has been resolved:

net: Remove conflicting altnames for dying netns in __dev_change_net_namespace().

syzbot reported the warning in cfg80211_pernet_exit(). [0]

The repro does the following:

  1. create two device in root netns and non-root netns
  2. assign the same altname for the two devices
  3. remove the non-root netns

Since commit 7663d522099e ("net: check for altname conflicts when changing netdev's netns"), cfg80211_switch_netns() and cfg802154_switch_netns() fail if init_net has a device with the conflicting altname.

default_device_exit_net() had the same issue and commit d09486a04f5d ("net: fix removing a namespace with conflicting altnames") fixed it.

cfg80211_pernet_exit() and cfg802154_pernet_exit() need the same fix.

Let's generalise the fix by removing conflicting altnames for dying netns in __dev_change_net_namespace().

[0]: cfg80211_switch_netns(rdev, &init_net) WARNING: net/wireless/core.c:1871 at cfg80211_pernet_exit+0xd5/0x120 net/wireless/core.c:1871, CPU#1: kworker/u8:9/1160 Modules linked in: CPU: 1 UID: 0 PID: 1160 Comm: kworker/u8:9 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/24/2026 Workqueue: netns cleanup_net RIP: 0010:cfg80211_pernet_exit+0xd5/0x120 net/wireless/core.c:1871 Code: e8 03 42 80 3c 20 00 74 08 4c 89 f7 e8 b4 ef 0e f7 4d 8b 36 49 81 fe 20 10 4a 90 74 12 e8 03 3d 9f f6 eb 85 e8 fc 3c 9f f6 90 <0f> 0b 90 eb cc e8 f1 3c 9f f6 eb 05 e8 ea 3c 9f f6 5b 41 5c 41 5e RSP: 0018:ffffc900057a78f0 EFLAGS: 00010293 RAX: ffffffff8b287154 RBX: ffff88807ba72780 RCX: ffff8880213e8000 RDX: 0000000000000000 RSI: 00000000ffffffef RDI: 0000000000000000 RBP: 00000000ffffffef R08: ffffffff9024cc67 R09: 0000000000000000 R10: fffff52000af4eb0 R11: fffffbfff204998d R12: dffffc0000000000 R13: ffffffff904a1080 R14: ffff888144ed0008 R15: ffff888144ed0e20 FS: 0000000000000000(0000) GS:ffff888124de6000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005642de0a8a70 CR3: 000000007a40c000 CR4: 00000000003526f0 Call Trace: <TASK> ops_exit_list net/core/net_namespace.c:200 [inline] ops_undo_list+0x43d/0x8d0 net/core/net_namespace.c:253 cleanup_net+0x572/0x810 net/core/net_namespace.c:706 process_one_work kernel/workqueue.c:3387 [inline] process_scheduled_works+0xc3d/0x1630 kernel/workqueue.c:3470 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3551 kthread+0x38b/0x480 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK>

Executive ViewAI

Why It Matters

A local denial-of-service weakness in the Linux kernel's wireless networking namespace cleanup path could allow a user with CAP_NET_ADMIN in a network namespace to trigger a kernel warning; on systems configured with panic_on_warn=1 this can escalate to a full system outage. The issue affects Linux kernels using cfg80211/cfg802154, particularly where unprivileged user namespaces are enabled, but no public exploit has been identified at time of analysis and default configurations are limited to a warning.

Business Impact: Medium
Compensating Controls

No vendor-released patch identified at time of analysis. Interim mitigations include disabling unprivileged user namespaces where they are not required, restricting CAP_NET_ADMIN to trusted processes, ensuring panic_on_warn=0 on production hosts to prevent warning-triggered panic, avoiding conflicting alternative interface names across root and non-root network namespaces, and monitoring kernel logs for cfg80211_pernet_exit WARN_ON splats.

Threat Intelligence Overview

EPSS Score
0.2%
Top 95% exploitable
Prevalence
Ubiquitous
Linux kernel networking core; present in essentially all deployments, wireless-netns path narrower
Data Quality
4 sources
Confidence: Medium

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.2%
Patch available No
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Defer
Exploitation· derived
None
System Exposure· derived
Small
Automatable· derived
No
Human Impact
Medium

Priority Score

39
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +39
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 16.0 Affected

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