CIFSwitch — локальная уязвимость в CIFS-подсистеме Linux открывает путь к root-доступу

28 мая 2026 года исследователь Asim Manizada публично раскрыл CIFSwitch — локальную уязвимость повышения привилегий на Linux-системах, где сочетаются уязвимое ядро, cifs-utils и разрешённые пользовательские пространства имён. Это не удалённая атака через интернет, но для серверов с несколькими пользователями, контейнерами, хостингом или CI-инфраструктурой риск серьёзный: локальный непривилегированный пользователь при определённых условиях может получить root-доступ.

CIFSwitch затрагивает связку ядра Linux и cifs-utils

CIFSwitch относится к классу LPE — local privilege escalation, то есть локального повышения привилегий. Такой баг не позволяет атакующему «с улицы» сразу подключиться к серверу и стать администратором. Но если у злоумышленника уже есть обычная учётная запись, доступ к контейнеру, веб-шелл, скомпрометированный сервисный пользователь или возможность запускать код на машине, уязвимость может стать ступенькой к полному захвату системы.

Публичное раскрытие появилось в рассылке oss-security 28 мая 2026 года. В сообщении указывается, что проблема находится на границе между CIFS-клиентом ядра Linux и пользовательским пакетом cifs-utils, а первоначально она была передана сопровождающим kernel/CIFS 16 мая. На момент публикации CloudLinux также отмечала, что отдельный CVE-идентификатор для CIFSwitch ещё не был назначен.

CIFS/SMB — это механизм доступа к сетевым файловым ресурсам, знакомый многим по Windows-шарам, Samba-серверам и корпоративным файловым хранилищам. В Linux часть работы выполняет модуль ядра, а для Kerberos/SPNEGO-аутентификации используется пользовательский helper cifs.upcall из пакета cifs-utils. Именно в этой связке и возникла опасная логическая ошибка.

Ошибка связана с доверенными описаниями cifs.spnego

В нормальном сценарии ядро Linux формирует специальное описание запроса cifs.spnego, где указываются параметры вроде UID, credential UID, PID и целевого namespace. Затем через механизм request_key() запускается обработка, а /sbin/request-key по правилу из /etc/request-key.d/cifs.spnego.conf вызывает cifs.upcall с root-привилегиями.

Слабое место оказалось в том, что до исправления ядро не отбрасывало описания cifs.spnego, созданные из пользовательского пространства. Иначе говоря, непривилегированный процесс мог сформировать поддельный запрос, который выглядел для цепочки обработки как доверенный запрос от CIFS-подсистемы.

Дальше cifs.upcall, запущенный с повышенными правами, начинал доверять полям, которые фактически контролировал атакующий. В техническом разборе исследователя объясняется, что цепочка использует пользовательские и mount namespaces, а также поведение NSS-загрузки. Для обычного читателя суть проще: компонент, которому доверяли как внутреннему запросу ядра, можно было обмануть поддельными данными из обычного пользовательского процесса.

Уязвимость опасна не на всех Linux-системах

Важная деталь CIFSwitch — это не универсальная «кнопка root» для любого Linux. Для успешной эксплуатации должны совпасть несколько условий:

Условие	Практический смысл
Уязвимое ядро с соответствующим CIFS-кодом	Система должна содержать проблемный путь обработки `cifs.spnego`
Установленный cifs-utils	Нужен helper `cifs.upcall` и правило request-key
Доступность CIFS-модуля ядра	Модуль должен быть загружаемым или встроенным
Разрешённые unprivileged user namespaces	Атаке нужен переход в контролируемое пространство имён
Отсутствие блокировки со стороны SELinux/AppArmor	Некоторые политики могут ломать цепочку эксплуатации

Именно поэтому исследователь называет проблему «non-universal» — неуниверсальной. Одни дистрибутивы и конфигурации могут быть уязвимы из коробки, другие — только после установки дополнительных пакетов или ослабления политик безопасности, а третьи могут блокировать цепочку настройками LSM.

Для серверов это всё равно серьёзный сигнал. Пакет cifs-utils часто устанавливают не потому, что он нужен постоянно, а «на всякий случай» — например, для разового подключения сетевой папки. На рабочих станциях риск ниже, если нет недоверенных локальных пользователей, но в средах с контейнерами, shared-хостингом, CI/CD-раннерами и множеством системных аккаунтов проверку лучше не откладывать.

Исправление закрывает поддельные запросы из пользовательского пространства

Ядерное исправление называется smb: client: reject userspace cifs.spnego descriptions. Его смысл — добавить проверку происхождения описания cifs.spnego и отклонять запросы, которые не были созданы самой CIFS-подсистемой через её доверенный путь.

CloudLinux в своём advisory указывает, что исправления и livepatch-обновления готовились для затронутых веток, а AlmaLinux на 28 мая 2026 года уже имела тестовые сборки для AlmaLinux 9 и 10. Для AlmaLinux 9 целевым исправленным пакетом назывался kernel-5.14.0-687.5.4.el9_8 или новее, для AlmaLinux 10 — kernel-6.12.0-211.7.4.el10_2 или новее.

Главный практический вывод: ориентироваться нужно не только на «номер версии Linux», а на обновления конкретного дистрибутива. Один и тот же upstream-баг может закрываться разными пакетами в Ubuntu, Debian, Fedora, AlmaLinux, CloudLinux, RHEL-подобных системах и корпоративных ядрах с backport-патчами.

Администраторам стоит проверить cifs-utils и пользовательские namespaces

Первый безопасный шаг — понять, есть ли на сервере компоненты, необходимые для атаки. Проверка не требует запуска exploit-кода и не меняет систему:

command -v cifs.upcall && cifs.upcall -V 2>/dev/null

ls -l /etc/request-key.d/cifs.spnego.conf 2>/dev/null

sysctl user.max_user_namespaces 2>/dev/null
sysctl kernel.unprivileged_userns_clone 2>/dev/null

Если cifs.upcall отсутствует, а пакет cifs-utils не установлен, типичная цепочка CIFSwitch становится недоступной. Если cifs-utils установлен, но SMB/CIFS-монтирования с Kerberos на сервере не используются, пакет стоит удалить штатным менеджером пакетов после проверки зависимостей.

Для Debian и Ubuntu это может выглядеть так:

sudo apt-get remove --purge cifs-utils

Для RHEL-подобных систем:

sudo yum remove cifs-utils

Ещё одна временная мера — запретить unprivileged user namespaces. Это может снизить риск не только для CIFSwitch, но и для ряда других локальных уязвимостей. Однако такой шаг способен сломать контейнерные сценарии, sandbox-механизмы браузеров, rootless Podman и некоторые dev-инструменты, поэтому его нельзя применять вслепую на продуктивных системах.

Пример для EL-семейства:

sudo sysctl -w user.max_user_namespaces=0
echo 'user.max_user_namespaces = 0' | sudo tee /etc/sysctl.d/99-cifswitch.conf

Для Debian/Ubuntu часто проверяют и параметр:

sysctl kernel.unprivileged_userns_clone

Если организация использует Kerberos-аутентификацию к SMB-шарам, грубое отключение cifs.upcall или удаление cifs-utils может нарушить рабочие подключения. В таких случаях безопаснее ускорить установку обновлённого ядра или livepatch, а временные меры согласовать с владельцами файловых ресурсов.

Риск выше для shared-хостинга, CI и серверов с недоверенным кодом

CIFSwitch особенно неприятен там, где запуск локального кода не является редкостью. Например, на shared-хостинге один пользователь не должен иметь возможность выйти за пределы своей учётной записи. В CI/CD-инфраструктуре pull request или build script не должен превращаться в root-доступ к раннеру. На сервере приложений с уязвимым веб-процессом локальный LPE может стать вторым этапом атаки после первичного проникновения.

Для одиночного домашнего компьютера сценарий менее драматичен: атакующему сначала нужно получить возможность запускать код локально. Но для серверной инфраструктуры это как слабый замок на двери внутри здания: с улицы его не видно, зато после попадания внутрь он открывает доступ в служебные помещения.

Следующий шаг — обновить ядро и убрать лишние компоненты

CIFSwitch — хороший пример уязвимости, которая выглядит узкой технической проблемой, но на практике упирается в базовую гигиену Linux-серверов. Если cifs-utils не нужен, его лучше не держать установленным. Если unprivileged namespaces не используются, их стоит ограничить. Если дистрибутив уже выпустил обновление ядра, его нужно установить и перезагрузить систему либо применить проверенный livepatch-механизм.

Минимальный план действий для администратора:

Проверить наличие cifs.upcall и правила cifs.spnego.
Сверить параметры user namespaces.
Проверить security advisory своего дистрибутива.
Установить исправленное ядро или livepatch.
Удалить cifs-utils там, где SMB/CIFS-клиент не используется.
После обновления вернуть временные ограничения только там, где они действительно мешают рабочим сценариям.

Главная мысль без паники: CIFSwitch не делает каждый Linux-сервер автоматически скомпрометированным, но системы с cifs-utils, разрешёнными пользовательскими namespaces и недоверенными локальными пользователями нужно проверить в приоритетном порядке.