CVE-2026-68152

What it actually does

This is a race-condition use-after-free in the Linux kernel AMT network driver delayed-work lifecycle. When an AMT network device is stopped or removed, the driver cancels pending request and discovery delayed work items, but another AMT event work item can requeue those delayed works after cancellation and before the AMT device structure is fully released. The requeued work can then dereference freed kernel memory associated with the AMT device, causing a kernel crash, memory corruption, or potentially other undefined kernel behavior. Practical exploitation likely requires the ability to create, open, stop, or remove AMT network interfaces, such as local administrative privileges or CAP_NET_ADMIN in a namespace/container where the AMT driver is available.

Why it matters to the business

Systems running affected Linux kernels may be exposed to local denial-of-service risk through kernel panics or instability, especially where untrusted users, workloads, or containers have network-administration capabilities. Because this affects kernel memory safety, organizations should treat it as higher priority on multi-tenant Linux hosts, container platforms, virtualization hosts, appliances, and systems where AMT networking is enabled or loadable. It is not currently listed in CISA KEV and no public exploit maturity is reported, which lowers immediate mass-exploitation urgency, but kernel fixes should still be applied through normal expedited patch processes.

How an attack unfolds

An attacker first needs a way to exercise the Linux kernel AMT network-device code path, typically by loading or using the AMT driver and creating an AMT network interface. They then repeatedly trigger lifecycle transitions such as opening, stopping, and removing the AMT device while causing AMT event work to run. During teardown, the vulnerable driver cancels some delayed work items, but event work can requeue request or discovery work after that cancellation. If the network device is freed before the requeued delayed work executes, the delayed work operates on the stale AMT device pointer. The most likely observable result is a kernel oops, panic, reboot, or service outage; in worst cases, the stale pointer dereference may corrupt kernel memory.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix changing AMT teardown to disable delayed work synchronously so it cannot be requeued after cancellation. Apply vendor kernel updates from the relevant Linux distribution, appliance vendor, cloud image provider, or embedded platform maintainer as soon as they are available. If immediate patching is not possible, reduce exposure by disabling or blacklisting the AMT kernel module if AMT is not required, preventing untrusted users and containers from receiving CAP_NET_ADMIN, blocking module loading where operationally feasible, and restricting creation/removal of AMT network devices to trusted administrators only. Reboot systems after kernel updates where required so the fixed kernel is actually running.

How to confirm the fix worked

Confirm the running kernel version contains the vendor backport or upstream fix for the AMT delayed-work use-after-free; checking only the installed package version is insufficient if the host has not rebooted into the patched kernel. Verify whether the AMT driver is present or loaded using kernel module and configuration checks, and confirm whether AMT interfaces can be created. On systems that should not use AMT, validate that the module is unavailable, blacklisted, or blocked by module-loading policy. For patched systems, stress-test AMT interface create/open/stop/delete lifecycle operations in a non-production environment and confirm no kernel oops, KASAN use-after-free, or panic messages appear in kernel logs.

Typical attack path

1. Obtain local access with permission to manage network interfaces, or control a container/workload granted CAP_NET_ADMIN where the AMT driver is available.
2. Ensure the AMT driver is loaded or trigger autoloading by creating an AMT network device.
3. Create and open an AMT network interface to initialize and enable its delayed work queues.
4. Race AMT event handling against interface stop/removal by repeatedly bringing the device up/down or deleting and recreating it.
5. Cause event work to requeue request or discovery delayed work after teardown cancellation has completed.
6. Allow the requeued delayed work to execute after the AMT device structure has been freed.
7. Trigger a kernel use-after-free, resulting in a crash, memory corruption, or other kernel instability.

How to detect it

To determine whether this was already exploited, review kernel logs, system journals, crash dumps, and audit telemetry for AMT-related kernel faults or repeated AMT network-interface lifecycle activity. Useful sources include journald, dmesg, /var/log/kern.log, /var/log/messages, kdump/vmcore records, auditd logs for privileged network administration, endpoint telemetry showing iproute2 activity, and container runtime audit logs showing workloads granted CAP_NET_ADMIN. Look for kernel oops, panic, KASAN, KFENCE, or general-protection-fault messages with AMT functions such as amt_event_work, amt_dev_stop, request work, or discovery work in the stack trace. Also investigate bursts of commands or netlink activity that create, delete, bring up, or bring down AMT interfaces, especially from untrusted users or containers. Absence of these artifacts does not prove non-exploitation, because a successful denial-of-service may leave only limited pre-crash logs unless persistent kernel logging or crash dumping was enabled.

• BUG: KASAN: use-after-free
• KFENCE: use-after-free
• general protection fault
• kernel BUG at
• Oops:
• Kernel panic - not syncing
• RIP: .*amt_
• Call Trace:.*amt_event_work
• Call Trace:.*amt_dev_stop
• Call Trace:.*amt_req_work
• Call Trace:.*amt_discovery_work
• amt_event_work
• amt_dev_stop
• amt_req_work
• amt_discovery_work
• ip link add .* type amt
• ip link delete .* type amt
• ip link set .* type amt
• modprobe amt
• /sys/module/amt
• /proc/modules:.*amt

What your security team should do

• Prioritize patching Linux systems where untrusted users, containers, or automation have CAP_NET_ADMIN or equivalent network-device management privileges.
• Inventory systems with the AMT kernel driver available, loaded, or in use; treat exposed multi-tenant and container hosts as higher risk.
• Remove CAP_NET_ADMIN from untrusted containers and service accounts unless strictly required.
• If AMT is not used, disable or blacklist the AMT module until patched kernels are deployed.
• Monitor kernel logs for AMT-related crashes, use-after-free reports, or suspicious rapid AMT interface lifecycle activity.
• Ensure hosts are rebooted into the fixed kernel after package installation.
• Track vendor advisories for exact fixed kernel package versions because downstream distributions may backport the fix without changing to a visibly newer upstream kernel release.