Cloudanix VulnDB

CVE-2026-53324

Medium · 5.5

CVSS

5.5

EPSS

0.2%

Published

Jun 26, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in a Linux network driver can crash affected systems when certain virtual network devices are initialized.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Denial of service
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

This vulnerability is a Linux kernel denial-of-service flaw in the Microsoft Azure Network Adapter (MANA) network driver debugfs setup path. The affected code used unsafe and non-unique debugfs directory names for physical functions and virtual functions. For some virtual functions, particularly in VFIO passthrough or nested KVM scenarios, the driver could dereference a NULL PCI slot pointer, causing a kernel NULL pointer dereference and crash. Separately, non-unique debugfs names could cause debugfs_create_dir() failures when multiple devices share the same generated name. The practical technical impact is host or guest kernel instability when an affected MANA PCI device is initialized, passed through, probed, or reprobed.

Why it matters to the business

Systems using affected Linux kernels with MANA network devices, especially virtualized or passthrough configurations, may experience unexpected crashes or networking disruption. This can cause service downtime, failed VM startup or migration workflows, and operational instability in cloud or virtualization environments. The currently low EPSS score, absence from CISA KEV, and no known exploit maturity indicate lower immediate exploitation urgency, but availability-sensitive infrastructure should still prioritize kernel updates during normal maintenance windows.

How an attack unfolds

An attacker would need a path to influence initialization of an affected MANA PCI function, most plausibly by triggering device probe, reprobe, passthrough attachment, VM boot with an assigned VF, or similar virtualization lifecycle activity. In vulnerable kernels, the driver attempts to create a per-device debugfs directory using either a hardcoded physical-function name or pci_slot_name() for virtual functions. In environments where the PCI slot object is absent, pci_slot_name() dereferences a NULL pointer and the kernel faults. If successful, exploitation results in a kernel oops, panic depending on system panic-on-oops settings, network device failure, guest crash, or host instability. There is no indication from the provided data that this flaw enables privilege escalation, data theft, or remote code execution.

How to fix it

Update to a Linux kernel version that includes the MANA driver fix changing debugfs directory naming to pci_name(pdev). If consuming a vendor kernel, apply the relevant distribution, cloud image, hypervisor host, or appliance kernel update when available. Where immediate patching is not possible, reduce exposure by avoiding VFIO passthrough or nested virtualization configurations involving MANA VFs on affected kernels, avoid unnecessary driver bind/unbind or reprobe operations, and restrict administrative access capable of changing PCI passthrough or network device assignments. If MANA is not required, consider disabling or unloading the driver where operationally safe.

How to confirm the fix worked

Confirm the running kernel includes the fix by checking the vendor advisory, kernel changelog, or source tree for the MANA driver change that uses pci_name(pdev) for per-device debugfs directory names. Validate that the system is running the updated kernel after reboot, not only that the package is installed. On exposed systems, verify MANA devices initialize successfully under expected PF/VF, passthrough, and nested virtualization scenarios without kernel oops messages. Review /sys/kernel/debug, when debugfs is mounted, to confirm per-device MANA debugfs directories use unique PCI BDF-style names rather than hardcoded or slot-only names.

Typical attack path

  1. Identify a system or VM using an affected Linux kernel with the MANA network driver available or loaded.
  2. Obtain the ability to trigger PCI device initialization or lifecycle changes, such as VF passthrough assignment, VM start, device reprobe, or driver bind/unbind activity.
  3. Cause the affected MANA virtual function or physical function to be probed in a configuration where the PCI slot pointer is NULL or the generated debugfs name collides.
  4. The vulnerable driver attempts to create the debugfs directory using the unsafe or non-unique name.
  5. The kernel encounters a NULL pointer dereference or debugfs directory creation failure, resulting in device initialization failure, kernel oops, panic, guest crash, or service disruption.

How to detect it

Look for evidence of prior exploitation or triggering in kernel and system logs around VM boot, passthrough attachment, PCI device reprobe, or network driver initialization events. Relevant log sources include dmesg, journald, /var/log/kern.log, /var/log/messages, hypervisor management logs, libvirt logs, VM lifecycle audit logs, and crash dump facilities such as kdump or systemd-coredump where configured. Search for kernel oops or panic events involving the MANA driver, NULL pointer dereferences near PCI slot-name handling, debugfs_create_dir failures, and repeated device probe failures for MANA PCI devices. Correlate timestamps with administrative actions such as driver bind/unbind, VF assignment, VM start, VM migration, or nested virtualization tests. Because this is a kernel availability issue rather than a payload-based compromise, durable IOCs are limited; investigation should focus on crash artifacts, call traces, and suspicious or unauthorized device lifecycle activity immediately preceding outages.

  • mana
  • mana_probe
  • Microsoft Azure Network Adapter
  • NULL pointer dereference
  • BUG: kernel NULL pointer dereference
  • Oops:
  • Kernel panic - not syncing
  • debugfs_create_dir
  • -EEXIST
  • File exists
  • pci_slot_name
  • /sys/kernel/debug
  • /sys/kernel/debug/mana
  • /sys/bus/pci/drivers/mana
  • /sys/bus/pci/drivers/mana/bind
  • /sys/bus/pci/drivers/mana/unbind
  • vfio-pci
  • VFIO
  • nested KVM

What your security team should do

  • Inventory Linux systems and VM images that use the MANA network driver, especially cloud instances, virtualization hosts, nested KVM environments, and VFIO passthrough deployments.
  • Prioritize patching availability-critical systems where MANA VFs are assigned to guests or where VM lifecycle automation frequently attaches and detaches PCI devices.
  • Track distribution and cloud-provider kernel advisories for CVE-2026-53324 and deploy the fixed kernel as part of the next maintenance cycle.
  • Until patched, restrict access to operations that can bind, unbind, reprobe, or assign MANA PCI devices to virtual machines.
  • Monitor kernel logs for MANA driver probe failures, NULL pointer dereferences, debugfs directory creation errors, and unexpected host or guest reboots.
  • If kernel.panic_on_oops is enabled, assess whether this vulnerability could turn an otherwise recoverable oops into a full system outage and plan maintenance accordingly.

The record

In the Linux kernel, the following vulnerability has been resolved: net: mana: Use pci_name() for debugfs directory naming Use pci_name(pdev) for the per-device debugfs directory instead of hardcoded "0" for PFs and pci_slot_name(pdev->slot) for VFs. The previous approach had two issues: 1. pci_slot_name() dereferences pdev->slot, which can be NULL for VFs in environments like generic VFIO passthrough or nested KVM, causing a NULL pointer dereference. 2. Multiple PFs would all use "0", and VFs across different PCI domains or buses could share the same slot name, leading to -EEXIST errors from debugfs_create_dir(). pci_name(pdev) returns the unique BDF address, is always valid, and is unique across the system.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities