Короче, ребята, по поводу того, что в ядре Linux нашли критическую дыру CVE-2026-31431.

Если кратко: это локальный root за один проход. Без танцев с бубном, без рейс-кондишнов и бесконечных циклов. Просто запускаешь скрипт на 700 байт - и ты админ.

Косяк зарыт в криптографической подсистеме (режим authencesn). Там при записи влетает лишних 4 байта мимо буфера. Но самое паршивое - куда они влетают. Они ложатся прямо в page cache. То есть на диске бинарник (тот же /usr/bin/su) чистый и хеш-суммы сходятся. Но в оперативке он уже модифицирован. Ядро верит кэшу, исполняет этот мусор в памяти и дает рута. Причем можно вылезти даже из контейнера.

Я протестировал эксплойт на разных виртуалках в разных клаудах и везде мне удалось легко получить root. Поэтому, если прямо сейчас у вас есть какие-то пользователи на ваших серверах - нужно срочно установить системные обновления/патчи на ваши сервера ( с ребутом ).

Если такой возможности нет, то делаем так:

### Отключаем какашку
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead

### Смотрим что какашки больше нет и сбрасываем кеши
lsmod | grep algif
echo 3 > /proc/sys/vm/drop_caches

### Протестировать будет ли воспроизводиться эксплойт можно еще так:
python3 -c 'import socket;
  s = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET, 0);
  s.bind(("aead","authencesn(hmac(sha256),cbc(aes))"));
  print("algif_aead successfully loaded, mitigation not effective; remove it with: # rmmod algif_aead")'

Patch now, cry later. Хорошей пятницы 😕

---
Telegram | Github | YouTube | Twitter

Если вы не успели обновить свои серваки, чтобы закрыть CVE-2026-31431, то и правильно сделали =)). Вышла уже новая критическая уязвимость – Dirty Frag. И снова любой локальный пользователь может поднять свои права до root.

Проблема затрагивает почти все дистрибутивы Linux, вышедшие с 2017 года. Похожа на недавний Copy Fail (см. предыдущий пост). Эксплойт уже в открытом доступе на GitHub вместе с инструкцией, так что школо-хакеры и ботнеты подтянутся быстро.

На текущий момент (8 мая 2026) патчей в официальных репозиториях популярных дистрибутивов еще нет. Ждем обновлений ядра в ближайшие дни.

Пока нет патча делаем временный костыль – отключаем модули esp4, esp6 и rxrpc. Если они вам не критичны для работы, выполните в терминале:

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

Как только прилетят обновы ядра – сразу ставим и ребутаемся. Это единственный нормальный способ закрыть вопрос.

Технические подробности и сам код эксплойта лежат тут: https://github.com/V4bel/dirtyfrag

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

Шо опять? 😈

Пару часов назад Уильям Боулинг и команда V12 выложила свежайший эксплойт для повышения привилегий – встречайте Fragnesia.

Как это работает:
1. Создается lookup-таблица из 256 значений, сопоставляя байты кейстрима AES-GCM с нужными нам IV (nonce).
2. Сплайсятся данные из целевого файла в TCP-сокет, а затем происходит переключение его в режим espintcp.
3. Ядро пытается расшифровать данные прямо в кэше страниц. Подбирая IV, заставляем алгоритм XOR-ить именно тот байт, который нам нужен, превращая оригинальный код в наш шелл-код.
4. Заменяются первые 192 байта su в памяти на стаб, вызывающий /bin/sh с правами root. При этом файл на диске остается нетронутым

Временный фикс:

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

Похоже, мы вошли в эпоху, когда новости о критических уязвимостях в Linux выходят чаще, чем обновления в App Store. Не успели просохнуть патчи для первого Dirty Frag, как прилетела Fragnesia.

---
Telegram | Github | YouTube | Twitter

🔖Контейнер ≠ Docker [1/3]

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

На самом деле сама постановка вопроса уже говорит о низкой квалификации собеседующего. Почему? Сейчас объясню.

Современные контейнеры давно вышли за рамки исключительно Linux namespaces и cgroups, а официальный стандарт OCI вообще допускает контейнеры на базе виртуальных машин.

Согласно OCI-спецификации: контейнер – это изолированная среда для выполнения процессов с настраиваемыми ограничениями ресурсов и уровнями изоляции. Ключевой момент здесь – среда выполнения, а не сам процесс. То есть контейнер – это не просто “изолированный процесс Linux” как многие думают, а стандартизированная среда запуска.

Но это ещё не всё – OCI допускает контейнеры, построенные поверх виртуализации. В этом случае изоляция достигается не namespaces (cgroups, seccomp, capabilities etc), а гипервизором.

Самая известная реализация VM-контейнеров – Kata Containers. Kata запускает OCI-контейнеры внутри лёгких виртуальных машин.

Как итог это позволяет получить:

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

Более того мы можем научить docker cli использовать runtime kata. Снаружи это выглядит как обычный контейнер, а внутри – microVM:

docker run --rm -it --runtime kata --cpus 0.5 ubuntu nproc

Короче: если собеседующий задаёт этот вопрос – бегите. Он застрял в 2015 году и перепутал Docker с религией.

Ну а в следующих частях я расскажу как использовать Kata Containers и Firecracker практике. Покажу как развернуть эту всю историю на сервере и запускать microVM для достижения максимально изоляции.

Если вам интересна эта тема - ставьте 🔥 и всем хорошей пятницы.

---
Telegram | Github | YouTube | Twitter

🔖Когда графики в Grafana врут?

Хотите разобраться почему графики показывают разные данные в grafana на разных интервалах и дипазонах? Сейчас мы с вами за 4 шага разберемся почему так происходит…

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

• Окно в функции PromQL: increase(...[5m]).
• Interval: 10m.
• Глобальный диапазон: Last 7 days.

1. Какую сетку строит Grafana?

Смотрим на поле Interval – Grafana уже сама все посчитала и поставила 10m.

Interval один из самых важных параметров. Grafana использует его и в запросах в PromQL, и в визуализации панели.

Тут сработала математика самой Grafana: она взяла 7 дней, разделила на ширину панели в пикселях (Max data points = 1146), получила число в районе 8.6 минут и округлила его вверх до ближайшего красивого шага – 10 мин. Формула подсчета интервала там есть прямо рядом Time range / max data points.

В данном примере Grafana выполнит range query с шагом 10 минут: 12:00, 12:10, 12:20, 12:30...

Немного отвлечемся на другой немаловажный параметр - Min interval. Представим, что мы решили посмотреть детально и выделили на графике узкий отрезок – всего в 15 мин (вместо текущих 7 дней).

Исходя из формулы Interval = Time range / max data points получились бы интервалы в 0.76 сек. и это очень мало для корректной визуализации. Тут в игру вступает Min interval = 1m:

• Grafana видит, что расчетный шаг (0.76 сек) меньше, чем лимит (1m).
• Она говорит: “Окей, я не буду частить. Буду просить данные с шагом строго 1 мин.”.

По сути Min Interval это защита от бессмысленных маленьких интервалов.

С этим вроде разобрались – погнали смотреть что в запросе PromQL.

2. Какое окно считает Prometheus?

Когда Prometheus выполняет запрос для каждой точки, он видит твою функцию increase(...[5m]). Это значит в этой конкретной точке оглянись назад ровно на 5 минут и посчитай прирост счетчика.

Складываем это вместе и смотрим на хронологию:

• Точка 12:10: Prometheus смотрит назад на 5 мин. – оценивает отрезок с 12:05 до 12:10. Отдает значение. Grafana рисует точку.
• Точка 12:20: Prometheus делает шаг в 10 мин., встает на новую точку и снова смотрит назад на 5 минут – оценивает отрезок с 12:15 до 12:20.

3. Главный инсайт – на графике появились “слепые зоны”!

Заметили, что произошло?

• 1 точка покрыла интервал 12:05 - 12:10.
• 2 точка покрыла интервал 12:15 - 12:20.

А куда делся промежуток времени с 12:10 до 12:15? Он просто выпал из расчетов. Он не попал ни в первую точку, ни во вторую.

Когда интервал шага на графике (10m) больше, чем окно в самой функции ([5m]) – наше временное окно больше не скользит с пересечением. Оно начинает прыгать через промежутки времени, оставляя слепые зоны.

Если в промежуток с 12:10 до 12:15 бахнет жесткий всплеск – график его вообще не покажет, потому что Prometheus физически не заглянет в этот пятиминутный отрезок.

4. Как это исправить, чтобы график стал адекватным?

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

Самый правильный путь – переписать запрос на rate с динамическим интервалом $__rate_interval = max( $interval + scrape_interval , 4 × scrape_interval ).

$__rate_interval значительно уменьшает вероятность появления слепых зон и делает поведение графика гораздо стабильнее при смене диапазона.

rate(postfix_smtp_messages_processed_total{...}[$__rate_interval])

На самом деле $__rate_interval довольно крут тем, что на широких дипазонах Grafana сама передаст Prometheus окно в 10m подстроившись под шаг графика. А если бы мы смотрели узкий диапазон (например, 15 мин), то:

• interval = 0.76 с.
• 4 × scrape_interval = 1 мин.
• Итоговое окно = 1 мин. (а не 0.76 сек.)

То есть $__rate_interval всегда не меньше 1 мин (или 4×scrape_interval), что защищает от слишком маленьких окон.

А на этом у меня всё – ставьте лайки, задавайте вопросы

Telegram | Github | YouTube | X