Re: [PATCH] crypto: af_alg - Remove zero-copy support from AF_ALG

[Demi Marie Obenour <demiobenour@gmail.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 2268 bytes --]

On 5/4/26 02:56, Eric Biggers wrote:
> On Mon, May 04, 2026 at 02:54:27AM -0400, Demi Marie Obenour wrote:
>> On 5/4/26 02:15, Eric Biggers wrote:
>>> 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 huge
>>> recipe for TOCTOU vulnerabilities.
>>>
>>> While zero-copy support is more valuable in other areas of the kernel
>>> like the frequently used networking and file I/O code, it has far less
>>> value in AF_ALG, which is a niche UAPI.  AF_ALG primarily just exists
>>> for backwards compatibility with a small set of userspace programs such
>>> as 'iwd' that haven't yet been fixed to use userspace crypto code.
>>>
>>> Originally AF_ALG was intended to be used to access hardware crypto
>>> accelerators.  However, it isn't an efficient interface for that anyway,
>>> and it turned out to be rarely used in this way in practice.
>>>
>>> Thus, the risks of the zero-copy support in AF_ALG vastly outweigh its
>>> benefits.  Just remove it.
>>>
>>> Note that this isn't a hard break, since the splice syscall is still
>>> supported.  The data is just now copied instead.  So it still works,
>>> just a bit slower in some cases.
>>>
>>> Tested with libkcapi/test.sh.  All its test cases still pass.  I also
>>> verified that this would have prevented the copy.fail exploit as well.
>>>
>>> Fixes: 8ff590903d5f ("crypto: algif_skcipher - User-space interface for skcipher operations")
>>> Fixes: 400c40cf78da ("crypto: algif - add AEAD support")
>>> Reported-by: Taeyang Lee <0wn@theori.io>
>>> Reported-by: Feng Ning <feng@innora.ai>
> [...]
>> In light of https://lore.kernel.org/all/afYcc-tZFwvZZo76@ans-MacBook-Pro.local/,
>> yes please!
>>
>> Should there be a Link: tag referencing that email?
> 
> Yes I forgot to put that in, sorry.  It should go after the second
> Reported-by:
> 
>     Link: https://lore.kernel.org/r/afYcc-tZFwvZZo76@ans-MacBook-Pro.local
> 
> - Eric

Should this also link to copy.fail or a related email?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]