The Linux cryptography subsystem is preparing to remove support zero-copy from the interface AF_ALG for algorithm types SKCIPHER e AEAD. The change is already in the cryptodev tree and is expected to be sent for merging during the upcoming window Linux 7.2, which is scheduled to open in June. This action is prompted by growing security concerns surrounding zero-copy mechanisms in the kernel, especially following recent vulnerabilities in the Linux cryptographic code.
AF_ALG — rappresenta user interface to the Linux kernel cryptographic API. Through it, programs can access implementations of ciphers, hashes, and AEAD algorithms in the kernel as sockets. The Linux documentation separately describes the zero-copy mode for AF_ALG through splice() and vmsplice(), where the kernel tries to avoid unnecessary data copying into kernel memory.
The issue is that for AF_ALG, this performance gain has proven less significant, while the risks are too high. The author of the change, Linux cryptographic subsystem developer Eric Bigger from Google, ha indicato, che il zero-copy consente allo spazio utente di eseguire operazioni crittografiche direttamente sulle pagine della cache dei file, come ad esempio l'eseguibile su, e crea anche condizioni per vulnerabilità TOCTOU, dove la memoria può essere modificata contemporaneamente all'operazione che la riguardano.
In altre parole, il meccanismo, utile nell'input/output di rete o file, in AF_ALG appare come un'ottimizzazione troppo rischiosa. Lo stesso AF_ALG, secondo lo sviluppatore, è attualmente conservato principalmente per la retrocompatibilità con un piccolo set di programmi, come iwd, che non sono ancora stati portati alla crittografia nello spazio utente. Inizialmente, AF_ALG era pensato anche per accedere agli acceleratori crittografici hardware, ma si è dimostrato non un'interfaccia molto efficace per questo compito.
È importante notare che non si tratta di una rimozione totale di splice() o sendfile() per AF_ALG. La modifica è descritta come un «soft break» della compatibilità: il passaggio dei dati nelle richieste AF_ALG tramite splice() e sendfile() continuerà a funzionare, ma il kernel adesso creerà una copia interna stabile dei dati prima dell'operazione crittografica. Le prestazioni potrebbero diminuire in alcuni casi, ma l'API utente formalmente non si guasta.
Si sottolinea inoltre che nel frattempo il zero-copy viene rimosso da skcipher e aead. Il supporto per il tipo hash sarà esaminato separatamente.
Il contesto della modifica è sgradevole. A fine aprile è stata svelata una vulnerabilità Copy Fail (CVE-2026-31431) in algif_aead, ossia proprio nell'interfaccia crittografica utente di AF_ALG. I ricercatori hanno dimostrato che la combinazione di AF_ALG, splice() e le peculiarità del trattamento AEAD permetteva a un utente non privilegiato di danneggiare la cache delle pagine, inclusa quella delle pagine corrispondenti ai binari setuid, ottenendo così un'elevazione dei privilegi a root.
Il sorgere Copy Fail era legato all'ottimizzazione del 2017, che ha trasferito le operazioni AEAD alla gestione "in situ"; durante il trasferimento di un file tramite splice() in AF_ALG, il kernel lavorava non con una copia, ma con riferimenti alle pagine della cache. Di conseguenza, parte dei dati ritenuti solo in ingresso poteva trovarsi nel scatterlist in scrittura.
La rimozione dello zero-copy da AF_ALG non è una correzione mirata a una sola vulnerabilità. Piuttosto, si tratta di un tentativo di eliminare un'intera classe di scenari rischiosi da un UAPI poco utilizzato, dove il guadagno dall'ottimizzazione non giustifica la complessità e le potenziali conseguenze. Per gli utenti comuni, questa modifica rimarrà probabilmente invisibile; per alcuni rari software che utilizzano attivamente AF_ALG tramite splice() o sendfile(), potrebbe verificarsi una diminuzione delle prestazioni a causa della copia aggiuntiva.
Fonte: linux.org.ru
