CVE-2026-46077

What it actually does

This is a local Linux kernel availability flaw in the Atmel Triple-DES hardware crypto driver. The driver synchronizes a DMA output buffer with the wrong DMA direction before the CPU reads it, which can cause the CPU to consume stale cache data on non-coherent DMA platforms. In practical terms, a local user able to trigger affected crypto operations may cause incorrect crypto results, driver instability, hangs, or kernel-level availability impact. The issue requires local access with low privileges and is not known to be remotely exploitable.

Why it matters to the business

Systems that rely on affected Linux kernels with the Atmel TDES crypto driver on susceptible hardware may experience outages, instability, or service disruption if the flaw is triggered. The risk is most relevant to embedded, appliance, and ARM-based platforms using Atmel/Microchip crypto acceleration. Public exploitation is not currently known, EPSS is very low, and the issue is not in CISA KEV, but affected systems should still be patched through normal kernel maintenance because the impact is high availability loss on exposed platforms.

How an attack unfolds

An attacker first needs local access to a system running an affected Linux kernel where the Atmel TDES hardware crypto driver is present and usable. The attacker then repeatedly invokes Triple-DES operations through a path that reaches the kernel crypto API and the atmel-tdes driver. Because the driver performs DMA cache synchronization using the device direction instead of the CPU direction, the CPU may read stale output data after DMA completion on non-coherent platforms. Repeated triggering can destabilize crypto operations or the driver path and may result in denial of service through hung operations, kernel instability, or system disruption. There is no indication from the provided data that this vulnerability enables remote code execution, privilege escalation, data theft, or ransomware deployment.

How to fix it

Upgrade to a vendor-supplied Linux kernel that includes the fix for the Atmel TDES DMA synchronization direction issue. No exact fixed package versions were provided, so use distribution, appliance, or board-vendor advisories to identify the first kernel build containing the upstream fix described as “crypto: atmel-tdes - fix DMA sync direction.” After installing the patched kernel, reboot into the updated kernel and verify the old kernel is no longer running. Where immediate patching is not possible, reduce exposure by disabling, unloading, or blacklisting the atmel-tdes driver if it is not required; disabling hardware crypto acceleration for Triple-DES; restricting local shell access; and limiting untrusted workloads on affected devices. If the driver is built directly into the kernel, mitigation generally requires a patched kernel or a rebuilt kernel without the affected driver enabled.

How to confirm the fix worked

Confirm the running kernel has been updated to a build that contains the Atmel TDES DMA synchronization fix. Check the active kernel version after reboot, not only the installed package version. Validate whether exposure exists by checking for Atmel TDES hardware, kernel configuration options, and loaded modules associated with the atmel-tdes driver. Review `/proc/crypto` for Triple-DES algorithms backed by Atmel hardware and check `lsmod`, kernel config, or boot logs for the driver. If mitigation was chosen instead of patching, confirm the driver is not loaded and cannot be auto-loaded, or that the relevant hardware crypto path is disabled. Functional validation should include running representative crypto workloads and confirming there are no kernel warnings, hangs, or crypto operation failures in `dmesg` or system logs.

Typical attack path

1. Obtain local access to a Linux system with low-privileged credentials or code execution.
2. Confirm the system is running an affected kernel and that the Atmel TDES crypto driver is present, loaded, or available.
3. Trigger Triple-DES crypto operations that are serviced by the atmel-tdes driver, potentially through the Linux kernel crypto API.
4. Cause the driver to process DMA output buffers where stale cache data may be consumed by the CPU due to incorrect synchronization direction.
5. Repeat or stress the operation to induce crypto failures, hangs, kernel instability, or denial of service.

How to detect it

There are no unique public indicators of exploitation for this issue from the provided data. Detection should focus on signs of local triggering and resulting instability on systems where the atmel-tdes driver is present. Review kernel logs, `dmesg`, system journal, audit logs, crash dumps, watchdog reset records, and uptime/reboot history for unexplained hangs or crashes around crypto activity. If audit coverage exists, look for unusual local processes repeatedly creating AF_ALG crypto sockets or invoking Triple-DES operations. Investigate recent module-load events involving the Atmel TDES driver, unexpected access by low-privileged users to crypto interfaces, repeated application failures involving encryption/decryption operations, and kernel warnings or oops events from the crypto subsystem or DMA paths. Because stale-cache DMA faults often do not leave a clean exploit signature, absence of logs does not prove absence of exploitation; correlate system instability with local user activity and crypto workload timing.

What your security team should do

• Prioritize patching affected embedded, appliance, ARM, or Atmel/Microchip-based Linux systems where the atmel-tdes driver is present or hardware crypto acceleration is enabled.
• Inventory systems for the affected driver and hardware before broad emergency action; generic x86 Linux servers without this driver are unlikely to be practically exposed.
• Schedule a kernel update and reboot through standard maintenance channels, ensuring the running kernel contains the upstream fix.
• If patching is delayed, disable or blacklist the atmel-tdes driver where operationally safe, and restrict local access to trusted administrators and workloads.
• Monitor affected systems for unexplained kernel hangs, watchdog resets, crypto API errors, or repeated local crypto stress activity.
• Do not treat this as an internet-facing remote exploitation issue unless another vulnerability or management path gives an attacker local code execution first.