The Linux cryptography subsystem is preparing to remove support zero-copy from the interface AF_ALG for algorithm type SKCIPHER and Support for OpenVPN;. The change is already in the cryptodev tree and is expected to be sent for merging in the window that should open in June. This is due to growing concerns about the security of zero-copy mechanisms in the kernel, especially after recent vulnerabilities in the Linux cryptographic code. Linux 7.2, which is set to open in June. The reason for this is the increasing concerns about the security of zero-copy mechanisms in the kernel, particularly following recent vulnerabilities in the Linux cryptographic code.
AF_ALG — this is user interface to the Linux kernel cryptographic API. Through it, programs can access implementations of ciphers, hashes, and AEAD algorithms in the kernel as if they were sockets. The Linux documentation separately describes the zero-copy mode for AF_ALG via splice() and vmsplice(), where the kernel tries to avoid unnecessary copying of data into kernel memory.
The problem is that for AF_ALG, this performance gain is not considered significant, and the risks are too high. The author of the change, Eric Biggers from Google, indicated, notes that zero-copy allows user space to perform cryptographic operations directly on the pages of the page cache of files, such as the su binary, and also creates conditions for TOCTOU vulnerabilities, whereby memory can be altered simultaneously with operations on it.
In other words, a mechanism that is useful in network or file I/O seems to be too risky an optimization in AF_ALG. According to the developer, AF_ALG is currently mainly kept for backward compatibility with a small set of programs, such as iwd, that have not yet transitioned to cryptography in user space. AF_ALG was initially intended for access to hardware crypto accelerators, but in practice has proven to be an inefficient interface for this purpose.
Importantly, this is not a complete removal of splice() or sendfile() for AF_ALG. The change is described as a 'soft break' in compatibility: data transfer in AF_ALG requests through splice() and sendfile() will continue to work, but the kernel will now make an internal stable copy of the data before the cryptographic operation. Performance may degrade in some cases, but the user API is not formally broken.
It is also emphasized that while zero-copy is being removed from skcipher and aead. Support for the type hash will be considered separately.
The context of the change is unfavorable. At the end of April, a vulnerability was disclosed. Copy Fail (CVE-2026-31431) in algif_aead, which is exactly in the user crypto interface AF_ALG. Researchers demonstrated that the combination of AF_ALG, splice(), and specific features of AEAD processing allowed an unprivileged user to corrupt the page cache, including pages corresponding to setuid binaries, and to gain root privileges.
The emergence Copy Fail was linked to the 2017 optimization that moved AEAD operations to 'in-place' processing; when a file is transmitted via splice() in AF_ALG, the kernel works not with a copy, but with references to the pages in the page cache. As a result, part of the data that was considered input only could end up in the writable scatterlist.
The removal of zero-copy from AF_ALG is not just a targeted fix for a single vulnerability. Rather, it is an attempt to eliminate an entire class of risky scenarios from the little-used UAPI, where the benefits of optimization do not justify the complexity and potential consequences. For ordinary users, the change will likely go unnoticed; for rare programs that actively use AF_ALG through splice() or sendfile(), a drop in performance may occur due to additional copying.
Source: linux.org.ru
