CVE-2026-43276: Linux Kernel Use-After-Free Vulnerability

CVE-2026-43276 Overview

CVE-2026-43276 is a use-after-free vulnerability in the Microsoft Azure Network Adapter (MANA) driver within the Linux kernel networking subsystem. The flaw resides in the PCI service rescan code path and triggers a double destroy_workqueue() call against gc->service_wq. When mana_serv_reset() invokes mana_gd_suspend(), the cleanup routine destroys the service workqueue. If the subsequent mana_gd_resume() returns -ETIMEDOUT or -EPROTO, control falls through to mana_serv_rescan(), which calls pci_stop_and_remove_bus_device() and re-enters mana_gd_cleanup() through the PCI .remove callback. The second cleanup operates on a freed workqueue pointer, producing a kernel use-after-free crash.

Critical Impact
A use-after-free in the MANA Ethernet driver during PCI service rescan can crash the Linux kernel and destabilize Azure-hosted Linux workloads relying on MANA networking.

Affected Products

Linux kernel mana driver (drivers/net/ethernet/microsoft/mana)
Linux distributions running on Microsoft Azure with MANA-attached network adapters
Stable kernel branches addressed by commits a9a7c3203fdc, f975a0955276, and fa3c2f8d9152

Discovery Timeline

2026-05-06 - CVE-2026-43276 published to NVD
2026-05-06 - Last updated in NVD database

Technical Details for CVE-2026-43276

Vulnerability Analysis

The vulnerability is a use-after-free [CWE-416] caused by destroying the same workqueue twice along the MANA service rescan PCI path. The MANA driver uses gc->service_wq to dispatch service-related work items such as resets and rescans triggered by the host. During a service reset, the driver suspends the device, performs cleanup, and then attempts to resume it. The cleanup logic unconditionally calls destroy_workqueue(gc->service_wq) without invalidating the pointer, leaving a dangling reference inside the global context structure.

If the resume step fails with -ETIMEDOUT or -EPROTO, the driver escalates recovery by stopping and removing the PCI device. The PCI subsystem then calls the driver's .remove handler, mana_gd_remove(), which itself invokes mana_gd_cleanup() a second time. The second invocation operates on the already-freed workqueue, corrupting memory and triggering a kernel crash on the worker thread executing mana_serv_func().

Root Cause

The root cause is missing state tracking in mana_gd_cleanup(). The function does not check whether gc->service_wq has already been destroyed and does not set the pointer to NULL after destruction. Any code path that legitimately re-enters cleanup, such as the PCI remove callback after a failed resume, dereferences a stale pointer.

Attack Vector

The defective code path is exercised by host-initiated MANA service events combined with a failed resume operation. An attacker with the ability to influence host service signaling, induce timeouts on the management channel, or trigger PCI rescan conditions could provoke the double-destroy and crash the guest kernel. Local privileged users capable of stressing the driver during service operations can reach the same path. The patch fixes the issue by NULL-checking gc->service_wq in mana_gd_cleanup() and assigning NULL after destroy_workqueue() completes.

No public proof-of-concept exploit is available. Refer to the upstream patches for full technical context: Kernel patch a9a7c3203fdc, Kernel patch f975a0955276, and Kernel patch fa3c2f8d9152.

Detection Methods for CVE-2026-43276

Indicators of Compromise

Kernel oops or panic with mana_gd_cleanup+0x33/0x70 [mana] followed by mana_gd_remove+0x3a/0xc0 [mana] in the call trace.
Worker thread crashes referencing mana_do_service or mana_serv_func immediately after a failed mana_gd_resume().
dmesg entries showing -ETIMEDOUT or -EPROTO returned by MANA resume operations preceding a PCI device removal event.

Detection Strategies

Monitor kernel ring buffers and journalctl -k for the call stack signature involving pci_stop_and_remove_bus_device invoked from mana_serv_func.
Correlate Azure host service events with guest kernel instability by ingesting kernel logs into a centralized log platform.
Track running kernel version against the patched stable kernels (commits a9a7c3203fdc, f975a0955276, fa3c2f8d9152) across the fleet to identify exposed hosts.

Monitoring Recommendations

Forward /var/log/kern.log and dmesg output from MANA-equipped Azure VMs into a SIEM with kernel-crash alerting.
Alert on unexpected PCI removal events for mana devices, which indicate the failure path that triggers this bug.
Review host-side MANA service operation timing to surface repeated -ETIMEDOUT outcomes that precede the crash.

How to Mitigate CVE-2026-43276

Immediate Actions Required

Apply the upstream Linux kernel patch that NULL-checks gc->service_wq in mana_gd_cleanup() and clears the pointer after destruction.
Update Azure Linux guest images to a kernel build that includes commits a9a7c3203fdc, f975a0955276, or fa3c2f8d9152.
Reboot affected systems after patching to load the corrected mana module.

Patch Information

The fix is delivered through three Linux stable kernel commits: a9a7c3203fdc, f975a0955276, and fa3c2f8d9152. Each patch modifies mana_gd_cleanup() to skip workqueue destruction when gc->service_wq is NULL and assigns NULL after a successful destroy_workqueue() call. Distribution vendors should backport these commits to any LTS kernel that ships the MANA driver.

Workarounds

Avoid triggering host-side MANA service rescans on unpatched guests until kernels are updated.
Where feasible, restrict workloads requiring MANA networking to kernel versions that already include the fix.
Capture full kernel crash dumps via kdump so that any recurrence can be diagnosed and attributed to this code path.

bash

# Verify the running kernel includes the MANA cleanup fix
uname -r
modinfo mana | grep -E 'version|srcversion'
# Inspect recent kernel messages for the vulnerable call path
dmesg -T | grep -E 'mana_gd_cleanup|mana_gd_remove|mana_serv'