Cloudanix VulnDB

CVE-2026-90232

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A Linux kernel networking bug can freeze the system when certain tunnel configurations are removed, forcing administrators to reboot to regain control.

Exploitation
Local Privilege
Attacker needs
High Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

The AMT driver permits cross-network-namespace device linking but fails to correctly locate and unregister upper devices when the lower device is removed from a different namespace, resulting in a kernel warning and a blocked unregister_netdevice path that waits indefinitely.

Why it matters to the business

Administrators attempting to tear down network devices in environments using AMT tunnels across namespaces experience system hangs or forced reboots, disrupting network connectivity and requiring manual intervention to recover.

How an attack unfolds

An attacker with the ability to create an AMT device linked to a lower device in another namespace and then trigger unregistration of that lower device (via ip link del or equivalent) causes the kernel to enter the faulty unregister path, producing the splat and stalling the netdevice cleanup until the hung condition is cleared.

How to fix it

Upgrade to a kernel containing the fix that sets netns_immutable and rejects cross-netns AMT link creation; apply the separate fix for multiple upper-device unregistration when available.

How to confirm the fix worked

Attempt to create an AMT device with link-netns pointing to another namespace; the operation must now fail with an error instead of succeeding, and removal of lower devices must complete without warnings or stalls.

Typical attack path

  1. Create two network namespaces
  2. Add a veth pair spanning the namespaces
  3. Create an AMT upper device in one namespace over the veth in the other
  4. Trigger removal of the lower veth device
  5. Observe kernel warning and blocked unregister_netdevice

How to detect it

Search kernel logs for the unregister_netdevice_many_notify WARNING at net/core/dev.c combined with the message 'unregister_netdevice: waiting for ... to become free' and reference counts greater than zero during AMT device teardown.

What your security team should do

  • Identify any scripts or automation that create AMT devices spanning namespaces and rewrite them to stay within a single namespace
  • Schedule kernel updates that include the cross-netns prohibition
  • Monitor for the specific unregister_netdevice warning in kernel logs on systems that may still be vulnerable

The record

In the Linux kernel, the following vulnerability has been resolved: amt: Don't support cross-netns setup. When a lower device is unregistered, amt_device_event() tries to unregister its upper AMT device, but it has two problems. 1. amt_lookup_upper_dev() looks up an upper device in the lower device's netns only 2. amt_device_event() unregisters a single upper device only If AMT device is created on a lower device in another netns, removing the lower device triggers the splat below and gets stuck until all upper devices are removed. [0] The cross-netns setup seems unintentional considering 1. and the following points: * amt_link_setup() sets dev->netns_immutable to true * skb_scrub_packet() is not called in the fast path * iproute2 binary fails to find cross-netns lower device via link-netns: # ip -n ns1 link add amt0 link-netns ns2 type amt dev veth1 Cannot find device "veth1" Instead of supporting it properly and preparing for per-netns netdev unreg, let's forbid cross-netns setup. Note that the problem 2. needs a separate fix. [0]: WARNING: net/core/dev.c:12518 at unregister_netdevice_many_notify+0x1cce/0x2250, CPU#48: ip/2031 Modules linked in: CPU: 48 UID: 0 PID: 2031 Comm: ip Not tainted 7.2.0-rc5+ #27 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:unregister_netdevice_many_notify (net/core/dev.c:12518) Code: 89 ef e8 d5 52 ae fe e9 d0 f4 ff ff 48 8d 3d f9 3b 9c 02 48 c7 c6 c0 0b 63 84 ba ab 1f 00 00 67 48 0f b9 3a e9 65 ff ff ff 90 <0f> 0b 90 eb 81 48 8d 3d f6 3b 9c 02 48 c7 c6 c0 0b 63 84 ba e2 1f RSP: 0018:ffffc90004abf160 EFLAGS: 00010212 RAX: ffff888104d38260 RBX: ffff88800b0911b8 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff85b9f880 RBP: ffffc90004abf2d0 R08: ffffffff85b9f887 R09: 1ffffffff0b73f10 R10: dffffc0000000000 R11: fffffbfff0b73f11 R12: ffff88800b091d08 R13: ffff88800b091178 R14: dffffc0000000000 R15: ffff88800b091000 FS: 00007f555b86c600(0000) GS:ffff8881942a0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000562107d489c0 CR3: 0000000109a40002 CR4: 0000000000372ef0 Call Trace: <TASK> rtnl_dellink (net/core/rtnetlink.c:3632 net/core/rtnetlink.c:3674) rtnetlink_rcv_msg (net/core/rtnetlink.c:7112) netlink_rcv_skb (net/netlink/af_netlink.c:2556) netlink_unicast (net/netlink/af_netlink.c:1319) netlink_sendmsg (net/netlink/af_netlink.c:1900) ____sys_sendmsg (net/socket.c:775) __sys_sendmsg (net/socket.c:2738) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) ... unregister_netdevice: waiting for veth0 to become free. Usage count = 7 ref_tracker: netdev@ffff88800d7496d8 has 3/3 users at __netdev_adjacent_dev_insert (./include/linux/netdevice.h:4525 ./include/linux/netdevice.h:4554 net/core/dev.c:8791) __netdev_upper_dev_link (net/core/dev.c:8879 net/core/dev.c:8963) netdev_upper_dev_link (net/core/dev.c:9009) amt_newlink (drivers/net/amt.c:3321)

Affected packages

Ecosystem Package Introduced Fixed