Из AF_ALG в Linux убирают zero-copy из соображений безопасности
В подсистеме криптографии 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 позволяет пользовательскому пространству запускать криптографические операции непосредственно над страницами page cache файлов, например бинарника 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(), возможна просадка производительности из-за дополнительного копирования.
>>> Источник
