CVE-2026-46120

What it actually does

This is a Linux kernel use-after-free in the IPv6 GRE/ERSPAN tunnel link-change path. When an ip6erspan device is created or moved across network namespaces and then changed, the kernel can reinsert the tunnel into the wrong per-network-namespace hash table because ip6erspan_changelink() uses dev_net(dev) instead of the cached tunnel network namespace. The original namespace can retain a stale tunnel entry; when that namespace is destroyed, kernel cleanup walks freed memory, triggering KASAN slab-use-after-free reports and potentially a kernel BUG in network-device unregister logic. Because the vulnerable path is reachable from an unprivileged user namespace with a mapped root user and network namespace, a local low-privileged user may be able to crash the host kernel and, depending on exploitability and kernel hardening, potentially escalate privileges or corrupt kernel memory.

Why it matters to the business

Successful exploitation can destabilize or crash Linux systems that allow unprivileged user and network namespaces, affecting host availability and workloads that depend on those kernels. In shared compute, container, CI/CD, developer workstation, or multi-user environments, this increases the risk that a low-privileged local user or compromised workload can cause a denial of service or attempt kernel-level privilege escalation. The issue is not currently in CISA KEV, has no known mature public exploitation in the provided data, and has a low EPSS score, so urgency is highest for systems exposing untrusted local users, containers, or user-namespace-enabled workloads rather than internet-facing services.

How an attack unfolds

An attacker first obtains local code execution as a low-privileged user on a vulnerable Linux host. They create an unprivileged user namespace and network namespace, for example using unshare with user mapping and network namespace creation. Within that namespace context, they create or manipulate IPv6 GRE/ERSPAN tunnel interfaces and move or associate devices across network namespaces using rtnetlink operations. They then trigger a change operation on the ERSPAN tunnel so the kernel records the tunnel in the wrong namespace hash. Finally, they tear down the original namespace or otherwise cause namespace cleanup, which makes the kernel walk a stale freed tunnel entry. The immediate and most reliable result is a kernel crash or BUG; more advanced exploitation would attempt to shape heap allocations around the stale object to turn the use-after-free into privilege escalation or kernel memory corruption.

How to fix it

Apply the Linux kernel update that includes the upstream fix for ip6_gre/ip6erspan_changelink() using the cached tunnel network namespace instead of dev_net(dev). Because no exact fixed package versions were provided, use distribution security advisories and vendor kernel changelogs to identify the first patched kernel for each supported release stream. Prioritize upgrades on systems where unprivileged user namespaces are enabled, containers run with user namespace support, or untrusted users can execute local code. If immediate patching is not possible, reduce exposure by disabling unprivileged user namespaces where operationally feasible, restricting creation of network namespaces and tunnel interfaces, limiting CAP_NET_ADMIN in containers, preventing untrusted users from loading or using GRE/ERSPAN tunnel functionality, and applying container runtime/seccomp/LSM policies that block relevant rtnetlink tunnel management operations. Mitigations reduce attack surface but should not be treated as complete substitutes for a patched kernel.

How to confirm the fix worked

Confirm the running kernel package is at or above the vendor-fixed version for the affected distribution and release. Verify that the kernel source or vendor patch set contains the ip6_gre change that makes ip6erspan_changelink() use the cached tunnel network namespace, consistent with the already-correct ip6gre_changelink() behavior. On systems where mitigation is required, verify unprivileged user namespaces are disabled or restricted, container workloads do not receive unnecessary CAP_NET_ADMIN, and untrusted users cannot create network namespaces or ERSPAN/GRE tunnel links. Validation can include checking sysctl and distribution-specific namespace controls, reviewing container runtime capability policies, and testing that an unprivileged account cannot run user-plus-network namespace creation followed by tunnel creation. Avoid running proof-of-concept crash tests on production systems because successful validation may panic the kernel.

Typical attack path

1. Gain local execution on a vulnerable Linux system as an unprivileged user or through a compromised workload.
2. Create an unprivileged user namespace and network namespace, such as with user and network namespace unshare operations.
3. Create an IPv6 ERSPAN/GRE tunnel device using rtnetlink/iproute2-equivalent operations.
4. Move or manipulate the tunnel across network namespaces so the tunnel device's creation namespace and current device namespace diverge.
5. Invoke the ERSPAN tunnel change-link path, causing the tunnel to be inserted into the wrong per-network-namespace hash table.
6. Destroy or clean up the original network namespace, causing kernel namespace teardown to traverse a stale freed tunnel entry.
7. Trigger a kernel use-after-free, leading to a kernel BUG, system crash, or possible kernel memory corruption.

How to detect it

Look for evidence of local namespace and tunnel manipulation followed by kernel memory-corruption or crash symptoms. Primary sources are kernel logs, system journal, dmesg buffers, auditd logs, endpoint telemetry, container runtime logs, and command/process execution logs. Search for kernel messages mentioning KASAN slab-use-after-free, LIST_POISON1, unregister_netdevice_many_notify(), ip6gre, ip6erspan, ip6erspan_changelink(), ip6gre_exit_rtnl_net(), rtnetlink, and network namespace cleanup around the time of crashes or reboots. In process/audit telemetry, look for unprivileged users or containers invoking unshare with --user, --map-root-user, or --net, followed by ip link commands creating or changing erspan, ip6erspan, gre6, or ip6gre tunnel links. Also review container workloads granted CAP_NET_ADMIN and correlate namespace creation, tunnel configuration attempts, kernel BUG/Oops events, and unexpected host reboots. Absence of these artifacts does not prove non-exploitation because kernel panics may truncate logs, but their presence should trigger incident review and patch verification.

• KASAN: slab-use-after-free
• BUG: kernel NULL pointer dereference
• kernel BUG at net/core/dev.c
• LIST_POISON1
• unregister_netdevice_many_notify
• ip6gre_exit_rtnl_net
• ip6erspan_changelink
• ip6gre_changelink
• ip6erspan_newlink
• ip6_gre
• ip6erspan
• erspan
• gre6
• ip link add
• type ip6erspan
• type erspan
• type ip6gre
• unshare --user --map-root-user --net
• unshare -Urn
• RTM_NEWLINK
• RTM_SETLINK
• CAP_NET_ADMIN

What your security team should do

• Inventory Linux systems that permit unprivileged local users, container workloads, CI jobs, or user namespace creation, and prioritize them for kernel patching.
• Track vendor advisories for the specific Linux distributions in use and deploy the first kernel release that contains the ip6_gre/ip6erspan namespace fix.
• Where patching is delayed, disable or restrict unprivileged user namespaces and network namespace creation on systems that do not require them.
• Remove CAP_NET_ADMIN and other unnecessary network administration capabilities from containers and sandboxed workloads.
• Monitor kernel logs for KASAN use-after-free, LIST_POISON, unregister_netdevice, and ip6gre/ip6erspan-related crash traces that may indicate attempted exploitation or reliability testing.
• Review recent local user, container, and CI activity for suspicious namespace creation and tunnel-management commands.
• Treat unexplained kernel crashes involving ip6gre, ip6erspan, rtnetlink, or network namespace teardown as potentially security-relevant until patched.
• Because this issue is not currently KEV-listed and EPSS is low, align emergency response with local exposure: highest urgency for multi-tenant and container-hosting systems, lower urgency for tightly controlled single-purpose appliances without untrusted local execution.