CVE-2026-43056

What it actually does

This is a local Linux kernel use-after-free in the MANA network driver error path. If auxiliary_device_add() fails during auxiliary device creation, the cleanup path calls auxiliary_device_uninit(), which invokes a release callback that frees the containing mana_adev structure. The code may then continue using the embedded auxiliary device pointer, specifically accessing the saved device id after the backing object has been freed. In kernel context, this can lead to memory corruption, kernel crash, or potentially local privilege escalation if an attacker can reliably trigger and shape the freed memory reuse. The CVSS vector indicates local access with low attack complexity and low privileges required, with potential high confidentiality, integrity, and availability impact.

Why it matters to the business

Systems running affected Linux kernels with the MANA networking driver exposed could be at risk of local privilege escalation or denial of service. In practical terms, a user or process that already has limited local access may be able to crash the host or potentially gain elevated kernel-level privileges. This is most relevant for Linux workloads using Microsoft Azure Network Adapter/MANA support or kernels that include and load the affected driver. The EPSS score is currently very low, there is no known KEV listing, no ransomware association, and no public exploit maturity reported, so broad internet-scale exploitation is unlikely; however, kernel privilege escalation flaws remain important for multi-user systems, shared compute, container hosts, and cloud workloads where local code execution may already be available to an attacker.

How an attack unfolds

An attacker first needs local code execution with low privileges on a vulnerable Linux system where the affected MANA driver code can be reached. The attacker then attempts to cause the auxiliary device registration path in the MANA driver to fail, for example by inducing resource pressure, manipulating driver/device initialization conditions, or repeatedly exercising hotplug or initialization paths if available. When auxiliary_device_add() fails, the vulnerable cleanup path frees the mana_adev object and then later references data through the already-freed embedded auxiliary device. Depending on kernel configuration, allocator behavior, timing, and available primitives, this may cause an immediate kernel crash or may allow the attacker to influence freed kernel memory and convert the bug into privilege escalation. Successful exploitation would execute in kernel context, potentially allowing the attacker to bypass normal user-space permission boundaries.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the MANA driver add_adev() error path. The fix saves the allocated auxiliary device id before calling auxiliary_device_add() and avoids reading it from a potentially freed object during cleanup. Because no exact fixed package versions were provided, use the patched kernel versions supplied by the relevant Linux distribution, cloud image provider, appliance vendor, or kernel maintenance stream. Prioritize systems where the MANA driver is loaded or where Azure/MANA networking support is enabled. If immediate patching is not possible, reduce exposure by disabling or unloading unused MANA-related modules where operationally safe, restricting local shell access, limiting untrusted workloads, hardening container escape paths, and ensuring kernel lockdown, LSM policies, and least-privilege controls are in place. Reboot into the patched kernel after installation; merely installing a kernel package is not sufficient if the host continues running the old kernel.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel, not only the installed package, is a vendor build containing the MANA add_adev() use-after-free fix. Check the active kernel with uname -r and compare it against the distribution or vendor advisory for CVE-2026-43056. On source-based or custom kernels, verify that the MANA driver code saves the auxiliary device id in a local variable before auxiliary_device_add() and uses the saved value during cleanup after auxiliary_device_uninit(). Determine exposure by checking whether MANA-related modules are present or loaded, for example with lsmod, modinfo, or kernel configuration checks. Review boot and kernel logs for MANA driver initialization failures or KASAN/use-after-free reports. Validate that systems have rebooted into the patched kernel and that no vulnerable kernel remains selected as the default boot entry.

Typical attack path

1. Obtain low-privileged local execution on a Linux system running an affected kernel.
2. Confirm that the MANA networking driver or related auxiliary device path is present, loaded, or reachable.
3. Trigger the MANA auxiliary device creation path while forcing auxiliary_device_add() to fail.
4. Cause the vulnerable error-handling path to call auxiliary_device_uninit(), freeing the containing mana_adev object.
5. Take advantage of the subsequent stale access to the freed object to crash the kernel or attempt controlled kernel memory corruption.
6. If exploitation is reliable, escalate privileges or disable system availability.

How to detect it

There are no public, unique exploitation indicators for this vulnerability, and exploitation may leave little evidence beyond kernel instability or privilege-escalation artifacts. Detection should focus on kernel telemetry, crash data, authentication/activity logs, and evidence of local privilege escalation. Review dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore data, and KASAN reports for use-after-free warnings, kernel oopses, panics, or faults involving MANA driver functions and auxiliary device cleanup. Look for repeated MANA device initialization failures followed by crashes or unexpected privilege changes. Correlate any such kernel events with local user sessions, container activity, cron/systemd executions, sudo/su activity, new privileged processes, newly created setuid files, unexpected kernel module operations, and suspicious changes around the time of the crash. If available, use EDR or auditd telemetry to identify low-privileged processes that performed unusual hardware, sysfs, network-device, or module-related operations shortly before kernel faults. Because this is a local kernel issue and not a network protocol bug, network IDS is unlikely to provide reliable detection.

• BUG: KASAN: use-after-free
• use-after-free in add_adev
• add_adev
• auxiliary_device_add
• auxiliary_device_uninit
• adev_release
• mana_adev
• mana
• mana_ib
• Microsoft Azure Network Adapter
• kernel BUG
• kernel oops
• general protection fault
• unable to handle kernel paging request
• panic: Fatal exception
• KASAN: slab-use-after-free

What your security team should do

• Inventory Linux systems and images that include or load the MANA networking driver, especially Azure-hosted Linux workloads and custom kernels with CONFIG_MICROSOFT_MANA or related MANA support enabled.
• Patch affected systems using the appropriate vendor-supplied kernel update and reboot into the fixed kernel.
• Prioritize multi-user hosts, container platforms, CI runners, bastion hosts, and systems where untrusted or semi-trusted users can execute local code.
• Where patching is delayed, disable unused MANA driver functionality if it is not required, and restrict local access to trusted administrators and workloads.
• Monitor kernel logs for use-after-free, KASAN, general protection fault, kernel oops, panic, or MANA driver initialization failure messages.
• Ensure endpoint and workload controls can detect suspicious local privilege escalation behavior after initial access, including unexpected root shells, new setuid binaries, kernel crash loops, or anomalous module interactions.
• Track Linux distribution advisories because exact fixed package versions vary by vendor and kernel maintenance branch.
• Treat post-exploitation investigation seriously if a crash or KASAN report references MANA, add_adev(), auxiliary_device_add(), auxiliary_device_uninit(), or adev_release().