CVE-2026-46019

What it actually does

This is a Linux kernel availability flaw in the Atmel AES crypto driver. The driver allocates four memory pages for an AES buffer but, during cleanup, releases only one page, leaking the remaining three pages each time the vulnerable allocation/cleanup path is exercised. A local user or local process that can cause repeated use of the affected crypto driver may gradually consume kernel memory, potentially leading to memory pressure, service instability, failed allocations, or a system-wide denial of service. The issue does not directly provide confidentiality or integrity impact based on the available description.

Why it matters to the business

Systems that use the affected Linux kernel driver may become unstable or unavailable if the vulnerable code path is repeatedly triggered, which can disrupt workloads, embedded appliances, industrial systems, or servers relying on Atmel hardware crypto support. Because exploitation requires local access and no public exploitation is currently indicated, the broad business risk is moderate, but availability-sensitive systems should still prioritize remediation during normal kernel maintenance windows.

How an attack unfolds

An attacker first needs local code execution or the ability to run a local workload on a system using the vulnerable Linux kernel and the Atmel AES crypto driver. The attacker then repeatedly triggers AES operations that cause the driver to allocate and later clean up its internal buffer. Because the cleanup routine frees only one of four allocated pages, each iteration leaves additional kernel memory unreleased. Over time, repeated triggering can exhaust available memory or create severe memory pressure. The eventual outcome may be degraded performance, failed kernel or user-space allocations, process termination by the OOM killer, service interruption, or a full system denial of service. There is no indication from the provided data that this vulnerability enables remote compromise, privilege escalation, data theft, or ransomware activity.

How to fix it

Apply a Linux kernel update from the relevant distribution, device vendor, or kernel maintainer that includes the fix changing the Atmel AES cleanup logic to release the full allocation with the correct page order. No exact fixed package versions were provided, so track vendor advisories for the affected kernel branches and update to the first patched kernel available for the platform. Where immediate patching is not possible, reduce exposure by disabling or unloading the affected Atmel AES driver if it is not required, preventing untrusted local users from running arbitrary workloads, and limiting access to interfaces that can repeatedly invoke hardware-backed AES operations. Reboot after kernel replacement where required to ensure the patched kernel is running.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel version matches a vendor build containing the fix, not merely that an updated package is installed on disk. Where source validation is possible, confirm the Atmel AES cleanup path uses free_pages() with ATMEL_AES_BUFFER_ORDER rather than free_page() for the buffer allocated with __get_free_pages(). Check whether the atmel-aes driver is present or loaded using standard module and kernel configuration inspection. For exposure validation, determine whether the system uses Atmel AES hardware crypto and whether untrusted local users or workloads can invoke the affected crypto path. After patching or mitigation, run representative AES crypto workloads while monitoring free memory, slab usage, kernel logs, and OOM events to confirm memory is not steadily leaking.

Typical attack path

1. Gain local access to a system running an affected Linux kernel with the Atmel AES crypto driver available or loaded.
2. Identify or invoke a local interface that uses the kernel crypto API backed by the Atmel AES driver.
3. Repeatedly trigger AES buffer allocation and cleanup operations through crypto workloads.
4. Cause unreleased kernel pages to accumulate over time because cleanup frees only part of the allocated buffer.
5. Drive the system into memory pressure, OOM events, service instability, or denial of service.

How to detect it

There are no unique network indicators for this issue because exploitation is local and the vulnerability manifests as kernel memory leakage. To assess whether it may have been abused, review kernel logs, system journals, audit logs, and endpoint telemetry for unexplained memory pressure, repeated OOM killer events, kernel allocation failures, service crashes, or workload patterns that repeatedly invoke AES crypto operations on systems using the Atmel AES driver. Useful log sources include dmesg, journalctl kernel messages, /var/log/kern.log, /var/log/messages, auditd process execution logs, EDR process telemetry, container/job scheduler logs, and system performance metrics. Focus on timelines where memory steadily declined without a corresponding user-space process retaining memory, especially if the atmel-aes module was loaded and local users or jobs were running crypto-heavy workloads. Look for repeated execution of crypto test tools, benchmarking utilities, custom binaries, or scripts shortly before OOM events. Absence of these artifacts does not prove non-exploitation, because the leak occurs in kernel memory and may not leave a distinct exploit signature.

• atmel-aes
• atmel_aes_buff_cleanup
• ATMEL_AES_BUFFER_ORDER
• Out of memory: Killed process
• oom-killer
• page allocation failure
• Memory allocation failure
• invoked oom-killer
• crypto testmgr
• tcrypt

What your security team should do

• Inventory Linux systems, appliances, and embedded devices that run kernels with the Atmel AES crypto driver or Atmel hardware crypto support.
• Prioritize patching for availability-sensitive systems, multi-user systems, and systems where untrusted local code can run.
• Update to a vendor-supported kernel containing the fix and reboot into the patched kernel.
• If patching is delayed, disable or unload the atmel-aes driver where operationally safe and document any functionality impact.
• Restrict local shell, container, job execution, and workload submission access to trusted users until remediation is complete.
• Monitor affected systems for sustained memory growth, OOM killer activity, kernel allocation failures, and repeated crypto workload execution.
• Because EPSS is very low and the issue is not in the Known Exploited Vulnerabilities catalog, treat this as a local availability hardening issue rather than an active widespread exploitation emergency unless local abuse indicators are present.