В подистемата на криптографията на Linux се подготвя премахване на поддръжката zero-copy от интерфейса AF_ALG за типове алгоритми SKCIPHER и AEAD. Промяната вече е в дървото cryptodev и се очаква да бъде изпратена в прозореца за сливане Linux 7.2, който трябва да се отвори през юни. Причината са нарастващите опасения около безопасността на zero-copy механизмите в ядрото, особено след последните уязвимости в криптографския код на Linux.
AF_ALG — това е потребителски интерфейс към криптографския API на ядрото на Linux. Чрез него програмите могат да обращат към реализации на шифри, хешове и AEAD алгоритми в ядрото като към сокети. Документацията на Linux отделно описва за AF_ALG zero-copy режим чрез splice() и vmsplice(), при който ядрото се опитва да избегне ненужно копиране на данни в паметта на ядрото.
Проблемът е, че в случая с AF_ALG този печалба в производителността се оказа не толкова важна, а рисковете — твърде големи. Автор на промяната, разработчик на криптографската подсистема на Linux, е Ерик Биггерс от Google, бележи, който заявява, че zero-copy позволява на потребителското пространство да извършва криптографски операции директно върху страниците на кеша на файла, например бинарния файл su, а също така създава условия за TOCTOU уязвимости, когато паметта може да се променя едновременно с операцията върху нея.
С други думи, механизмът, полезен в мрежовото или файлното въвеждане-извеждане, в AF_ALG изглежда като твърде опасна оптимизация. Самият AF_ALG, според разработчика, в момента основно се запазва ради обратно съвместимост с малък набор от програми, например iwd, които още не са преминали на криптография в потребителското пространство. Първоначално AF_ALG е замислен и за достъп до хардуерни криптоскоростители, но на практика се оказа не толкова ефективен интерфейс за тази задача.
Важно е, че става дума не за пълно премахване на splice() или sendfile() за AF_ALG. Промяната се описва като "мека повреда" на съвместимостта: предаването на данни в AF_ALG заявки чрез splice() и sendfile() ще продължи да работи, но ядрото сега ще прави вътрешна стабилна копия на данните преди криптографската операция. Производителността в някои случаи може да намалее, но потребителският API формално не се прекършва.
Отделно се подчертава, че за сега zero-copy се премахва от skcipher и aead. Поддръжката за тип hash ще бъде разгледана отделно.
Контекстът за промяната е неприятен. В края на април беше разкрита уязвимост. Copy Fail (CVE-2026-31431) в algif_aead, тоест точно в потребителския криптоинтерфейс AF_ALG. Изследователите показаха, че връзката между AF_ALG, splice() и особеностите на AEAD-обработката позволяваше на непривилегирован потребител да повреди page cache, включително страниците, свързани с setuid-бинарници, и да получи повишаване на привилегиите до root.
Появата Copy Fail беше свързана с оптимизация от 2017 година, която премести AEAD-операциите на обработка «на място»; при предаване на файл през splice() в AF_ALG ядрото работеше не с копия, а с връзки към страници на page cache. В резултат част от данните, които се считаха само за входни, можеха да се окажат в записвания scatterlist.
Премахването на zero-copy от AF_ALG не е точечно поправяне само на една уязвимост. По-скоро това е опит да се премахне цял клас рисковани сценарии от малко използваното UAPI, където печалбата от оптимизация не оправдава сложността и потенциалните последствия. За обикновените потребители промените вероятно ще останат незабележими; за редки програми, които активно използват AF_ALG чрез splice() или sendfile(), е възможно да има спад в производителността поради допълнителното копиране.
Източник: linux.org.ru
