CVE-2026-46221

What it actually does

This is a Linux kernel memory leak in the Versal NET EDAC driver. During memory-controller initialization, the driver allocates a device name with kzalloc() and assigns it to dev->init_name. device_register() copies that name and clears dev->init_name, leaving the original allocation unreachable on the normal device removal path. Repeated initialization and removal of the affected EDAC device can steadily consume kernel memory. The flaw does not provide code execution, privilege escalation, or data disclosure by itself, but it can degrade availability and potentially contribute to a local denial-of-service condition through memory exhaustion.

Why it matters to the business

Systems running affected Linux kernels on hardware using the Versal NET EDAC driver may become unstable or unavailable if a local attacker or faulty automation repeatedly triggers the vulnerable device lifecycle. The practical risk is lower than remotely exploitable vulnerabilities because exploitation requires local access and a relevant hardware/driver configuration, and there is no known KEV listing or mature public exploit activity indicated. However, kernel memory exhaustion can still cause service disruption, failed workloads, degraded reliability, or emergency reboots on affected systems.

How an attack unfolds

An attacker first obtains local access with enough privileges to interact with the affected kernel device path, driver binding controls, module lifecycle, or other mechanisms that cause the Versal NET EDAC memory-controller device to be initialized and removed. The attacker repeatedly triggers probe/register and removal/unregister cycles. Each cycle leaks the allocated device-name buffer because the kernel loses the pointer after device_register() clears dev->init_name. Over time, unreclaimed kernel memory accumulates. If the loop continues long enough, the system may experience memory pressure, allocation failures, out-of-memory events, service degradation, or a crash/reboot. Exploitation is constrained to affected Linux kernels with the relevant EDAC/versalnet code path present and reachable.

How to fix it

Apply a Linux kernel update from the operating-system, appliance, or embedded platform vendor that includes the upstream fix for the EDAC/versalnet device-name memory leak. The fix changes the device-name handling to use a stack-local character buffer instead of heap allocation, preventing the leak on normal removal. Because no exact fixed package versions were provided, track vendor advisories for the deployed distribution or board support package and upgrade to the first kernel build that includes this patch. Where immediate patching is not possible, reduce exposure by disabling or avoiding use of the Versal NET EDAC driver if it is not operationally required, restricting local administrative access, preventing untrusted users from managing kernel modules or sysfs driver bind/unbind controls, and monitoring for repeated device reprobe/removal activity. Rebooting can temporarily reclaim leaked memory but is not a durable fix.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel build includes the EDAC/versalnet patch that removes kzalloc()-based init_name allocation in init_one_mc() and uses a stack-local name buffer. Validate through vendor package changelogs, kernel source inspection, or distribution security advisories. On source-based systems, inspect the affected driver code and confirm there is no persistent heap allocation assigned to dev->init_name for this device name. Where safe in a test environment, repeatedly bind/unbind or load/unload the relevant driver and observe that kernel memory usage does not grow monotonically. Runtime exposure can be checked by identifying whether the Versal NET EDAC driver is present or loaded and whether the system has matching hardware/device-tree entries. Also confirm that untrusted users cannot trigger driver lifecycle operations.

Typical attack path

1. Identify a Linux system running an affected kernel with the Versal NET EDAC driver present and relevant hardware or device-tree configuration.
2. Gain local access with privileges sufficient to trigger driver/device initialization and removal, such as via module management, sysfs driver bind/unbind operations, or platform device lifecycle controls.
3. Repeatedly cause the affected EDAC memory-controller device to be registered and removed.
4. Allow the leaked device-name allocations to accumulate in kernel memory.
5. Continue the cycle until kernel memory pressure causes degraded performance, allocation failures, service interruption, or system crash/reboot.

How to detect it

There are no unique network indicators for this vulnerability because exploitation is local and manifests primarily as kernel memory leakage. To assess possible prior exploitation, review kernel logs, audit logs, and system monitoring for repeated Versal NET EDAC driver initialization/removal activity followed by increasing kernel memory use, allocation failures, OOM-killer events, soft lockups, or unexpected reboots. Useful sources include journald, dmesg, /var/log/kern.log, /var/log/messages, auditd records for module-management commands, sudo logs, shell history for privileged users, and EDR telemetry for modprobe/rmmod or writes to sysfs driver bind/unbind files. On debug or test systems with kmemleak enabled, inspect kmemleak output for repeated leaked allocations associated with the EDAC/versalnet initialization path. Correlate suspicious activity with local user sessions and privilege elevation events. Absence of these artifacts does not fully rule out exploitation, especially if logs rotated or the system rebooted under memory pressure.

What your security team should do

• Prioritize patching affected Linux kernels on systems using Versal NET or related embedded/SoC platforms where the EDAC/versalnet driver is enabled.
• Inventory systems for the presence of the Versal NET EDAC driver and relevant hardware before assigning broad emergency priority, because exploitation depends on local access and a specific kernel code path.
• Restrict local shell access, sudo rights, kernel module management, and sysfs driver bind/unbind permissions to trusted administrators only.
• If the driver is not required, consider disabling or blacklisting it until a fixed kernel is deployed, after validating operational impact.
• Monitor for repeated driver load/unload or device bind/unbind activity involving EDAC or versalnet components, especially when followed by kernel memory pressure or OOM events.
• Use vendor-supported kernel packages rather than ad hoc source patches where possible, and schedule a reboot into the fixed kernel after installation.
• Treat unexplained kernel memory exhaustion on affected systems as potentially security-relevant and preserve logs before rebooting.