Linux AFALG Crypto Code Removing Zero-Copy Support Out Of Security Concerns

In a significant security-focused decision, the Linux kernel is removing zero-copy support from the AF_ALG (Async Crypto Layer) cryptographic interface due to growing security concerns. This change, which will affect SKCIPHER and AEAD algorithm types, represents a proactive approach to addressing potential vulnerabilities in the kernel's cryptographic subsystem.

Understanding AF_ALG and Zero-Copy

AF_ALG serves as the Linux kernel's interface for exposing cryptographic operations to user-space applications. Originally designed primarily for accessing hardware crypto accelerators, it has become a niche API used by certain programs like 'iwd' that haven't yet transitioned to userspace crypto implementations.

Zero-copy support in this context allowed applications to perform cryptographic operations directly on pagecache pages without the overhead of copying data between kernel and user space. While this approach can improve performance by reducing memory operations, it introduces significant security risks when implemented in kernel space.

Security Risks Outweigh Performance Benefits

Linux crypto expert Eric Biggers at Google, who authored the patch removing zero-copy support, explained the rationale behind this decision:

"The zero-copy support is one of the riskiest aspects of AF_ALG. It allows userspace to request cryptographic operations directly on pagecache pages of files like the 'su' binary. It also allows userspace to concurrently modify the memory which is being operated on, a recipe for TOCTOU (Time-of-Check to Time-of-Use) vulnerabilities."

The security concerns are particularly significant because:

1. Zero-copy operations allow direct access to sensitive pagecache pages
2. They enable concurrent modification of memory being processed
3. They create potential TOCTOU vulnerabilities
4. The risks are disproportionate to the benefits in this niche subsystem

Performance Impact Analysis

While the removal of zero-copy support will impact performance, the effect is expected to be minimal for most users. The change represents a "soft break" rather than a breaking change - the API remains functional, but the kernel now makes an internal, stable copy of data before performing cryptographic operations.

For typical workloads using AF_ALG, the performance degradation is likely to be modest. Applications that rely heavily on cryptographic operations might notice more significant impacts, but these are precisely the cases where userspace implementations would be more appropriate anyway.

Alternative Approaches Remain Functional

Importantly, the removal doesn't eliminate the ability to efficiently transfer data to AF_ALG sockets. Applications can still use splice() or sendfile() to transfer data from pipes or files directly to AF_ALG request sockets. The only change is that the kernel will make an internal copy before processing the data.

Broader Context in Linux Security

This decision comes amid increasing attention to kernel security vulnerabilities. The Linux community has been particularly vigilant about cryptographic subsystems, which are critical components for system security.

AF_ALG represents an interesting case study in security engineering - a niche interface where the security risks of a performance optimization outweigh its benefits. This contrasts with zero-copy support in other areas like networking and file I/O, where the performance advantages justify the security considerations.

Implementation Timeline

The patch removing zero-copy support is now in the "cryptodev" Git repository and is expected to be submitted for the Linux 7.2 merge window in June 2026. This timing suggests the change will be available in the Linux 7.2 release later in 2026.

For users and developers who rely on AF_ALG, the message is clear: while the interface will remain functional, they should plan for slightly reduced performance and consider migrating to userspace crypto implementations where possible. The security benefits of this change will likely outweigh the modest performance costs for most use cases.

Those interested in following the development can track the patch in the cryptodev Git repository and monitor the Linux 7.2 merge window for final integration.