HIGH 7.8

CVE-2026-46120

A flaw in the Linux kernel's IPv6 GRE tunnel implementation allows a local attacker with unprivileged user namespace capabilities to trigger memory corruption. The vulnerability stems from inconsistent netns (network namespace) handling in the ip6erspan_changelink() function, which fails to use the correct cached network namespace context when reconfiguring an ERSPAN tunnel after it has been migrated between namespaces. This can lead to kernel crashes and potential privilege escalation.

Source data · NVD / CISA · public domain

CVSS
3.1 · 7.8 HIGH · CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Weaknesses (CWE)
CWE-416
Affected products
5 configuration(s)
Published / Modified
2026-05-28 / 2026-06-24

NVD description (verbatim)

In the Linux kernel, the following vulnerability has been resolved: ip6_gre: Use cached t->net in ip6erspan_changelink(). After commit 5e72ce3e3980 ("net: ipv6: Use link netns in newlink() of rtnl_link_ops"), ip6erspan_newlink() correctly resolves the per-netns ip6gre hash via link_net. ip6erspan_changelink() was not converted in that series and still uses dev_net(dev), which diverges from the device's creation netns after IFLA_NET_NS_FD migration. This re-inserts the tunnel into the wrong per-netns hash. The original netns keeps a stale entry. When that netns is later destroyed, ip6gre_exit_rtnl_net() walks the stale entry, producing a slab-use-after-free reported by KASAN, followed by a kernel BUG at net/core/dev.c (LIST_POISON1) in unregister_netdevice_many_notify(). Reachable from an unprivileged user namespace (unshare --user --map-root-user --net). ip6gre_changelink() earlier in the same file already uses the cached t->net; only ip6erspan_changelink() has the wrong shape.

8 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-46120 is a use-after-free vulnerability (CWE-416) in the Linux kernel's IPv6 GRE ERSPAN tunnel driver. The ip6erspan_changelink() function incorrectly uses dev_net(dev) instead of the cached t->net value when re-inserting a tunnel into the per-netns hash table during reconfiguration. After a namespace migration via IFLA_NET_NS_FD, this causes the tunnel to be inserted into the wrong hash bucket while leaving a stale entry in the original namespace. When that original namespace is destroyed, ip6gre_exit_rtnl_net() dereferences the stale entry, triggering a slab-use-after-free condition detected by KASAN and culminating in a kernel BUG (LIST_POISON1) during device unregistration.

Business impact

This vulnerability presents a high-severity local denial-of-service risk with potential for privilege escalation. Any user capable of creating user namespaces can trigger namespace isolation features (unshare --user --net) to cause kernel panics on affected systems. Container orchestration platforms, cloud environments, and multi-tenant systems where unprivileged user namespace access is permitted face elevated risk of workload disruption and potential kernel compromise. Affected systems will experience unplanned downtime and require kernel patching to restore stability.

Affected systems

The Linux kernel is affected. The vulnerability is reachable from unprivileged user namespaces, making it exploitable on systems that permit user namespace creation by non-root users. Container environments, Kubernetes nodes, and systems running with user namespace delegation enabled are at particular risk. Verify your kernel version and namespace configuration against vendor advisories.

Exploitability

Exploitability is straightforward for local attackers with user namespace creation capability. The attack requires no special privileges beyond the ability to execute unshare(1) with --user, --map-root-user, and --net options to isolate into a new namespace and trigger tunnel reconfiguration. No authentication, network access, or kernel-level exploitation techniques are required. The triggering actions (namespace creation and tunnel migration) are standard operations in containerized and multi-tenant environments.

Remediation

Apply a kernel patch that corrects ip6erspan_changelink() to use the cached t->net value instead of dev_net(dev), aligning it with the earlier fix applied to ip6gre_changelink(). Verify the patch against the vendor advisory and rebuild the kernel. Systems should prioritize this update, particularly those running containerized workloads or permitting unprivileged namespace operations. Until patched, restrict unprivileged user namespace creation via sysctl (kernel.unprivileged_userns_clone=0) if operationally feasible.

Patch guidance

Contact your Linux distribution vendor for kernel updates addressing this issue. Patch timing should align with the CVE publication date (2026-05-28) and modification date (2026-06-24); check your vendor's security advisory portal for release schedules. Rebuild and test the patched kernel in a staging environment before production deployment. For container environments, update the host kernel first, then rebuild base images if kernel modules are embedded. Verify the specific kernel version numbers in your vendor's advisory before deployment.

Detection guidance

Monitor for KASAN warnings and kernel BUG messages related to ip6gre or ERSPAN tunnel operations in kernel logs. Watch for LIST_POISON1 panics during device unregistration (unregister_netdevice_many_notify). In container environments, track unexpected kernel panics correlated with namespace creation or IP tunnel reconfigurations. Intrusion detection signatures should flag suspicious unshare(1) calls with namespace isolation flags, especially in restricted environments. Kernel audit logs can capture namespace operations preceding crashes.

Why prioritize this

This vulnerability earns HIGH priority due to its CVSS 3.1 score of 7.8 and local denial-of-service impact combined with privilege escalation potential. Exploitability is trivial for unprivileged users in namespace-enabled systems, and affected infrastructure (containers, multi-tenant clouds) is widespread. Although active exploitation in the wild is not yet documented (KEV status is false), the ease of triggering and severity of impact (kernel panic, potential UAF escalation) warrant urgent patching. Container platforms should treat this as critical.

Risk score, explained

The CVSS 3.1 score of 7.8 reflects a local attack vector (AV:L), low attack complexity (AC:L), low privilege requirements (PR:L due to unprivileged namespace capability), and high impact across confidentiality, integrity, and availability (C:H/I:H/A:H). The score appropriately captures the seriousness of a use-after-free leading to kernel crashes and potential information disclosure or code execution. The absence of network attack surface and requirement for local access prevent a critical rating, but the triviality of exploitation and widespread affected infrastructure justify the HIGH severity designation.

Frequently asked questions

Can this vulnerability be exploited over the network?

No. CVE-2026-46120 requires local code execution capability. The attack is only reachable from unprivileged user namespaces on the same host, making it a local privilege escalation and denial-of-service vector, not a remote attack.

Does this affect systems with user namespace creation disabled?

Systems with kernel.unprivileged_userns_clone=0 or equivalent enforcement that blocks unprivileged user namespace creation are not exploitable via this specific vector. However, systems in containerized or cloud environments where namespace creation is intentionally enabled face full risk.

What is the difference between ip6erspan_changelink() and ip6gre_changelink()?

Both functions handle tunnel reconfiguration, but ip6gre_changelink() was correctly updated in commit 5e72ce3e3980 to use the cached t->net value. ip6erspan_changelink() was overlooked in that fix and retained the vulnerable dev_net(dev) call, causing namespace divergence during tunnel migration.

Will this cause data loss or data exposure?

Primary impact is denial-of-service (kernel panic). However, the underlying use-after-free condition could theoretically allow information disclosure or kernel code execution depending on memory layout and attacker sophistication, though such escalation is not documented in the initial advisory.

This analysis is provided for informational purposes and is based on the CVE description and CVSS vector provided as of the modification date. SEC.co does not provide exploit code or weaponized proof-of-concept instructions. Patch version numbers, affected product versions, and remediation timelines must be verified against official vendor advisories. Organizations should validate the applicability of this vulnerability to their specific kernel versions and namespace configurations before taking remediation action. This vulnerability intelligence does not constitute legal or regulatory compliance advice. Source: NVD (public-domain), retrieved 2026-07-07. Analysis generated by SEC.co (claude-haiku-4-5).

Affected vendors

Weaknesses (CWE)

Related vulnerabilities

  • CVE-2026-10001HIGH

    CVE-2026-10001: Chrome Sandbox Escape via PerformanceManager Use-After-Free

  • CVE-2026-10002HIGH

    CVE-2026-10002: Google Chrome PDFium Use-After-Free Vulnerability (CVSS 8.8)

  • CVE-2026-10003HIGH

    CVE-2026-10003: Chrome Use-After-Free Code Execution Vulnerability Analysis

  • CVE-2026-10007HIGH

    CVE-2026-10007: Chrome Use-After-Free in SVG Arbitrary Code Execution (CVSS 8.8)

  • CVE-2026-10012HIGH

    CVE-2026-10012: Chrome Skia Use-After-Free Sandbox Escape (v148.0.7778.216)

  • CVE-2026-10013HIGH

    CVE-2026-10013: Use-After-Free in Chrome WebCodecs – Patch Guide & Risk Assessment

  • CVE-2026-10016HIGH

    CVE-2026-10016: Use-After-Free in Chrome DOM – Sandbox Code Execution Vulnerability

  • CVE-2026-10882HIGH

    CVE-2026-10882: Critical Chrome Use-After-Free RCE Vulnerability – Exploit Details & Patch Guidance