CVE-2026-31743

What it actually does

This is a local Linux kernel memory-corruption vulnerability in the ZynqMP NVMEM driver. The driver uses an incorrect buffer size during coherent DMA allocation and memcpy operations, which can cause out-of-bounds DMA or memory copy access. If the vulnerable driver is present and reachable, a local authenticated user may be able to corrupt kernel memory, potentially causing kernel crashes, privilege escalation, or disclosure/modification of sensitive kernel data. The CVSS vector indicates local access, low attack complexity, low privileges required, no user interaction, and high confidentiality, integrity, and availability impact.

Why it matters to the business

Systems running affected Linux kernels on platforms that use the ZynqMP NVMEM driver may be exposed to local privilege escalation or denial of service. In practical terms, a compromised low-privileged account, container escape scenario, or malicious local process could potentially gain deeper control of the host or crash it. The EPSS score is currently very low, there is no known CISA KEV listing, and no public exploit maturity is reported, so broad internet-scale exploitation is unlikely at this time; however, kernel memory-corruption bugs remain high-impact when attackers already have local access.

How an attack unfolds

An attacker first needs local code execution with low privileges on a system using a vulnerable Linux kernel and the affected ZynqMP NVMEM driver. The attacker then interacts with the exposed NVMEM functionality in a way that causes the driver to allocate or copy data using the wrong buffer size. Because the DMA buffer or memcpy length does not match the actual required size, the operation can access memory outside the intended bounds. Depending on memory layout, kernel hardening, hardware configuration, and driver reachability, this may lead to a kernel panic, controlled kernel memory corruption, information disclosure, or possible elevation of privileges. There is currently no reported public exploit or known active exploitation, so exploitation details are expected to be highly platform-specific.

How to fix it

Apply a Linux kernel update from the relevant distribution, vendor, or embedded platform supplier that includes the fix for the ZynqMP NVMEM buffer-size handling issue. Because no exact fixed versions were provided, validate using vendor advisories, kernel changelogs, or source patches referencing "nvmem: zynqmp_nvmem: Fix buffer size in DMA and memcpy." Prioritize systems based on whether they run ZynqMP hardware or have the affected driver enabled. If immediate patching is not possible, mitigate by disabling or blacklisting the ZynqMP NVMEM driver where it is not required, removing unnecessary access to NVMEM device interfaces, limiting local shell access, enforcing least privilege, and using kernel hardening features such as lockdown, module signing, and LSM policy where applicable.

How to confirm the fix worked

Confirm exposure by checking whether the running kernel includes the vulnerable ZynqMP NVMEM code path and whether the driver is enabled, built in, or loaded. Review the running kernel package version and vendor changelog for the specific fix. On source-built kernels, verify that the patched buffer-size logic is present in the ZynqMP NVMEM driver. Confirm remediation by booting into the updated kernel and ensuring old vulnerable kernels are not still selectable as the default boot option. Where feasible in test environments, run kernel self-tests or platform-specific NVMEM access tests and monitor for kernel warnings, KASAN reports, DMA API warnings, oopses, or panics.

Typical attack path

1. Obtain local execution on a Linux system, for example through stolen credentials, a compromised service account, or another initial-access vulnerability.
2. Confirm the system is running an affected kernel with the ZynqMP NVMEM driver enabled and accessible.
3. Trigger NVMEM operations that reach the vulnerable DMA allocation and memcpy paths.
4. Cause undersized DMA buffer access or out-of-bounds memory copy behavior.
5. Use the resulting memory corruption to crash the kernel, disclose sensitive memory, or attempt privilege escalation to kernel/root-level control.

How to detect it

There are no public, vulnerability-specific indicators of compromise for this issue. To assess possible prior exploitation, review kernel logs, persistent journal entries, crash dumps, and monitoring telemetry for kernel oopses, panics, DMA API warnings, KASAN/KFENCE reports, or memory-corruption events occurring during NVMEM or ZynqMP driver activity. Correlate such events with local user sessions, privilege changes, new setuid binaries, unexpected kernel module activity, suspicious processes launched shortly before the crash, and authentication records showing low-privileged access. On embedded devices, also review device health logs, watchdog resets, unexplained reboots, and firmware management activity. Because successful exploitation may leave no unique artifact beyond kernel instability or post-exploitation behavior, absence of these logs does not prove the system was not exploited.

What your security team should do

• Inventory Linux systems using ZynqMP or embedded platforms likely to include the ZynqMP NVMEM driver.
• Prioritize patching affected systems where untrusted users, shared workloads, containers, or remote management users can obtain local execution.
• Update to a vendor kernel that includes the ZynqMP NVMEM buffer-size fix, and remove or de-prioritize old vulnerable kernels from boot menus.
• If patching is delayed, disable or blacklist the affected driver where operationally safe and restrict access to local accounts and device interfaces.
• Monitor kernel logs for crashes, DMA API warnings, KASAN findings, or oops reports involving ZynqMP NVMEM activity.
• Treat suspicious kernel crashes on affected systems as potential security events, especially if preceded by activity from low-privileged local users.
• Because EPSS is low, KEV is false, and no exploit maturity is reported, balance urgency against exposure: internet-facing status is less relevant than local access and platform use.