CVE-2026-53297

What it actually does

This is a Linux kernel denial-of-service flaw in the Microsoft Azure Network Adapter (MANA) network driver. If a power-management resume path fails, the driver cleanup routine can be invoked once during failed probe/resume handling and then invoked again later during device unbind. The first cleanup clears internal driver pointers; the second cleanup dereferences those now-NULL pointers, causing a kernel NULL pointer dereference and panic. The impact is system crash rather than code execution based on the available description.

Why it matters to the business

Systems using the affected Linux kernel MANA network driver can crash during specific device resume, probe-failure, or unbind sequences, causing workload interruption, network service downtime, failed jobs, and possible node replacement or reboot requirements. The issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS, and has no reported public exploit maturity, so broad internet exploitation is unlikely; however, availability-sensitive cloud workloads should still treat kernel updates as operationally important.

How an attack unfolds

An attacker would need a way to trigger or influence the relevant MANA device lifecycle sequence: a failed resume or attach path followed by a later driver unbind/removal. When the resume/probe path fails, the kernel calls the MANA cleanup routine, which tears down the device state and clears key pointers. Because the driver remains bound after a failed resume callback, a later unbind can call the same cleanup routine a second time. In vulnerable kernels, the second call does not verify that the driver context is already NULL before using it, resulting in a NULL pointer dereference in kernel context and a panic. In practice, exploitation is most plausible by a local privileged user, an administrator-level workload with access to device power-management or driver unbind controls, or through operational conditions that cause resume failure; there is no indication from the supplied data of remote unauthenticated exploitation.

How to fix it

Upgrade to a Linux kernel version that includes the MANA driver fix adding an early return when gdma_context or driver_data is NULL before dereferencing the device context. Because no product-specific fixed versions were provided, use the fixed kernel packages from the relevant Linux distribution, cloud image, appliance vendor, or upstream stable kernel branch once available. As a temporary mitigation, avoid unnecessary MANA driver unbind/rebind operations, device hotplug actions, and suspend/resume workflows on affected systems; restrict privileged access to sysfs driver controls and power-management operations; and schedule controlled reboots after kernel updates. Where feasible, use vendor-supported kernels and cloud images that have backported the net: mana fix.

How to confirm the fix worked

Confirm the running kernel includes the MANA driver patch by checking vendor advisories, package changelogs, or source for a guard in mana_remove() that returns early when gdma_context or driver_data is NULL before accessing gc->dev. Verify the installed and running kernel versions match the patched package after reboot. On systems using MANA, review loaded modules and interfaces with commands such as lsmod, modinfo, ethtool -i, dmesg, and journalctl to confirm the driver version and absence of post-update crash signatures. If safe in a non-production test environment, validate that failed resume/unbind scenarios no longer panic the kernel.

Typical attack path

1. Identify a Linux system using the MANA network driver, typically a cloud VM or host with a MANA-backed network interface.
2. Cause or wait for a MANA resume/probe failure where mana_attach() or the driver attach path returns an error.
3. Allow the failed path to invoke mana_remove(), which tears down device state and sets internal driver context pointers to NULL.
4. Trigger or wait for a later device unbind, driver removal, hotplug event, or equivalent lifecycle action that invokes mana_remove() again.
5. The vulnerable driver dereferences the cleared context pointer during the second cleanup call, causing a kernel panic and system outage.

How to detect it

Look for evidence of kernel crashes or oops events involving the MANA network driver, especially after suspend/resume, VM live migration, device hotplug, driver unbind, or failed network adapter initialization. Review system logs from journald, syslog, dmesg, kernel ring buffers, hypervisor or cloud serial console logs, and crash dump artifacts such as kdump vmcore files. Indicators include NULL pointer dereference messages, kernel panic/oops records, call traces containing mana_remove(), mana_probe(), mana_attach(), or MANA/GDMA driver functions, and log sequences showing MANA attach/resume failure followed by driver removal or unbind. Because exploitation requires a specific lifecycle error path and no public exploit maturity is indicated, distinguish malicious triggering from routine driver or platform instability by correlating crashes with local privileged actions, sysfs writes to driver bind/unbind controls, suspend/resume operations, cloud maintenance events, and administrative automation.

• mana_remove
• mana_probe
• mana_attach
• Microsoft Azure Network Adapter
• MANA
• gdma_context
• driver_data = NULL
• gc->dev
• NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Unable to handle kernel NULL pointer dereference
• Kernel panic - not syncing
• Call Trace:
• /sys/bus/pci/drivers/mana/unbind
• /sys/bus/pci/drivers/mana/bind
• /var/crash
• vmcore
• kdump
• journalctl -k

What your security team should do

• Prioritize patching Linux systems that use the MANA network driver and run availability-sensitive workloads, especially cloud VMs or hosts where network device lifecycle events may occur.
• Track distribution and cloud-provider kernel advisories for CVE-2026-53297 and deploy the first supported kernel package containing the net: mana double-invocation guard.
• Restrict root, sudo, container-privileged, and automation access that can write to sysfs driver unbind/bind paths or trigger power-management transitions.
• Monitor for kernel panics or NULL pointer dereferences involving mana_remove, mana_probe, mana_attach, or the mana driver around suspend/resume, hotplug, or unbind events.
• Ensure crash dump collection is enabled on critical Linux systems so suspected exploitation or recurrence can be confirmed from vmcore and kernel logs.
• Because EPSS is low, KEV is false, and exploit maturity is none, handle this as a reliability and local/privileged DoS risk rather than an emergency internet-facing remote compromise, unless local untrusted users or privileged workloads can manipulate device lifecycle controls.