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.

# 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'