Уязвимости в Linux и FreeBSD

5 уязвимостей в ядре Linux, раскрытых проектом Zero Day Initiative до публикации исправлений из-за ошибочной отправки информации не в тот список рассылки:

❤️ ZDI-CAN-33549 - уязвимость в модуле ksmbd c реализацией файлового сервера на базе протокола SMB, которую можно эксплуатировать для удалённого выполнения кода на уровне ядра. Доступен прототип эксплоита, работающий в Debian 13.
❤️ ZDI-CAN-33774 - состояние гонки в модуле ядра ksmbd, приводящее к записи в 40-байтовый буфер, выделенный для протокола SMB1, 62 байт данных из заголовка SMB2. Уязвимость может привести к удалённому выполнению кода при наличии доступа к SMB-хранилищу, обрабатываемому через ksmbd. Доступен прототип эксплоита, работающий в Debian 13.
❤️ ZDI-CAN-33367 - уязвимость в сетевом стеке ядра, позволяющая локальному пользователю получить права root в системе, перезаписав данные процесса в страничном кэше по аналогии с уязвимостями Dirty Frag и Fragnesia. Исправление доступно в форме патча. Из дистрибутивов пока только разработчики Alma Linux сформировали внеплановое обновление пакетов с ядром, в котором исправили данную уязвимость.
❤️ ZDI-CAN-34068 - переполнение буфера в графическом драйвере VMWGFX, применяемом для реализации 3D-ускорения в окружениях VMware. Проблема позволяет локальному пользователю получить права root в системе, при наличии доступа к виртуальному GPU через устройство /dri/card*. Доступен прототип эксплоита, работающий в Ubuntu 26.04
❤️ ZDI-CAN-34076 - уязвимость в драйвере nvmet (NVMe Target), приводящая к утечке информации о содержимом памяти ядра.

Набор уязвимостей "Infinity Core". Раскрыты сведения и опубликованы прототипы эксплоитов для 5 уязвимостей в ядре, позволяющих непривилегированному пользователю получить права root в системе и обойти изоляцию контейнеров. Проблемы уже устранены в актуальных выпусках ядра.

❤️ CVE-2026-98260 - обращение к памяти после её освобождения из-за повторного использования структуры POSIX-таймера, память под которую была освобождена в основном потоке после сбоя при выполнении вызова exec(), но ссылка осталась в очереди (timerqueue) в другом потоке. Доступен прототип эксплоита, работа которого была продемонстрирована в Ubuntu 26.04 и в Android на смартфоне Samsung Galaxy S26 Ultra.
❤️ CVE-2026-98256 - обращение к памяти после её освобождения из-за состояние гонки между вызовом exec() во вторичном потоке и очисткой очереди сигналов (sigqueue), ожидающих обработки. При манипуляциях с очередью может возникнуть ситуация, при которой ссылка на обработчик сигнала останется в очереди после освобождения связанной с ним памяти, и затем будет использована при обработке сигналов. Работа эксплоита продемонстрирована в Ubuntu 26.04.
❤️ CVE-2026-89754 - переполнение буфера в реализации системного вызова mincore(), возникающее из-за состояния гонки при повторном обходе таблиц страниц памяти после выполнения madvise(MADV_DONTNEED). Работа эксплоита продемонстрирована в Ubuntu 26.04.
❤️ CVE-2026-80775 - обращение к памяти после её освобождения в системном вызове prctl(), возникающее из-за некорректного отслеживания счётчиков ссылок для хешей фьютексов при возникновении состояния гонки между задачами, совместно использующими одну структуру mm_struct при вложенном вызове vfork(). Эксплоит, использующий уязвимость для перезаписи /usr/bin/passwd в страничном кэше, продемонстрирован в Ubuntu 26.04.
❤️ CVE-2026-98385 - обращение к памяти после её освобождения в обработчике кэша планировщика задач, возникающее из-за того, что планировщик обновляет поля со статистикой в структуре mm_struct для задачи после освобождения связанной с ней памяти в случае выполнения вызова exec() на другом ядре CPU. Уязвимость проявляется в ядрах с включённой опцией CONFIG_SCHED_CACHE. Работа эксплоита продемонстрирована в Arch Linux с ядром 7.2.4.

Опубликованы детали и эксплоиты для уязвимостей в ядре Linux, успешно использованных при взломах на проводимом компанией Google соревновании kernelCTF:

CVE-2026-23111, CVE-2023-31248, CVE-2023-3610, CVE-2026-23272, CVE-2026-23278,CVE-2026-23392, CVE-2026-23231 - обращения к памяти после её освобождения в Netfilter nftables.
CVE-2024-26583 - состояние гонки во встроенном TLS-сервере.
CVE-2025-38177 - обращение к памяти после её освобождения в подсистемах управления трафиком (HFSC, QFQ, netem qdiscs).
CVE-2025-38248 - обращение к памяти после её освобождения в реализации сетевых мостов (net/bridge).
CVE-2025-40214 - обращение к памяти после её освобождения в реализации UNIX-сокетов.
CVE-2026-23074 - обращение к памяти после её освобождения в ограничителе трафика sch_teql.
CVE-2026-23209, CVE-2026-23273 - обращения к памяти после её освобождения в обработчике macvlan.
CVE-2026-23274 - обращение к памяти до инициализации в netfilter xt_IDLETIMER.
CVE-2026-31418 - переполнение буфера в netfilter.
CVE-2026-31419 - обращение к памяти после её освобождения в драйвере net/bonding.
CVE-2026-43501 - переполнение буфера в обработчике IPv6-заголовка RPL Source Routing.

❤️ Уязвимость Vghost (CVE-2026-74580) в подсистеме ядра vhost, применяемой для ускорения операций ввода/вывода через Virtio в системах виртуализации. Уязвимость вызвана некорректной работой с кэшем таблиц трансляции адресов ввода-вывода (IOTLB) и может использоваться для повышения своих привилегий в системе и для обхода изоляции гостевой системы. При перенастройке адресов или размеров очередей (vring) через вызовы VHOST_SET_VRING_ADDR или VHOST_SET_VRING_NUM кэш vq->meta_iotlb[] не очищался, что приводило к трансляции новых адресов с использованием уже недействительных записей о маппинге памяти. Опубликован прототип эксплоита для получения прав root, протестированный в дистрибутивах Ubuntu 26.04, RHEL 9.8, Amazon Linux 2023.12.20260817, Azure Linux 3.0 и Oracle Linux 10.2.

Уязвимости во FreeBSD (устранены в обновлениях 15.1-RELEASE-p5, 14.5-RELEASE-p2 и 14.4-RELEASE-p11):

❤️ CVE-2026-101308 - обращение к памяти после её освобождения в драйвере sound, возникающее из-за состояния гонки между операцией изменения размера буфера и маппингом памяти через mmap. Уязвимость потенциально позволяет локальному пользователю, имеющему доступ к звуковому устройству, получить права root.
❤️ CVE-2026-101309, CVE-2026-101310, CVE-2026-101311 - уязвимости в компонентах гипервизора Bhyve, позволяющие через манипуляции в гостевой системе выполнить код на стороне хост-окружения. Проблемы вызваны выходом за границы буфера из-за состояния гонки в модели контроллера xHCI (USB 3), а также отсутствием должных проверок размера записей в моделях устройств HDA (High Definition Audio) и framebuffer.
❤️ CVE-2026-101307 - целочисленное переполнение в модуле tcp_rack c реализацией алгоритма определения потери пакетов RACK (Recent ACKnowledgment), приводящее к выделению буфера, слишком мелкого, чтобы вместить все полученные данные. Уязвимость позволяет перезаписать до 512 КБ в области за границей буфера при отправке большого числа ACK-пакетов в установленном TCP-соединении. Отмечается, что эксплуатация может привести к переводу ядра в состояние panic.

Linux / Линукс 🥸

6 GitHub-репозиториев для изучения DevOps

Kubernetes examples. Официальные примеры манифестов и приложений под k8s, на которых удобно разбираться, как это всё описывается на практике.
https://github.com/kubernetes/examples

Terraform AWS modules. Готовые проверенные модули под AWS. Отличный образец того, как писать переиспользуемый и аккуратный Terraform-код.
https://github.com/terraform-aws-modules/terraform-aws-modules

Prometheus. Исходники самой популярной системы мониторинга. Если хотите понять метрики и алертинг не на уровне дашбордов, а изнутри, это сюда.
https://github.com/prometheus/prometheus

Argo CD. GitOps-деплой в Kubernetes: состояние кластера описывается в git, а Argo приводит кластер к нему. Must-have для понимания современного CD.
https://github.com/argoproj/argo-cd

Kubernetes the Hard Way. Легендарный гайд Келси Хайтауэра: кластер поднимается полностью вручную, без скриптов и автоматики. Больно, но после него k8s перестаёт быть магией.
https://github.com/kelseyhightower/kubernetes-the-hard-way

The System Design Primer. Не совсем про DevOps, но без системного дизайна дальше джуна не уехать. Масштабирование, кеши, очереди, базы, всё с примерами.
https://github.com/donnemartin/system-design-primer

MemOps🤨

MemOps 😃

Практическое руководство по созданию локальной лаборатории платформенной инженерии с использованием vind, Sveltos и Argo CD. В нем рассматриваются GitOps, развёртывание на основе меток, исправление дрейфа конфигураций, а также сетевые проблемы, с которыми вы столкнетесь по ходу работы.

📌 Подробнее: https://itnext.io/local-platform-engineering-on-your-laptop-vind-sveltos-and-argocd-2b3e1341ebe7

MemOps🤨

MemOps 😃

Как VictoriaLogs хранит логи в колоночной структуре

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

📌 Подробнее: https://habr.com/ru/articles/1067552/

MemOps🤨

MemOps 😃

Как работает Docker 🐳

MemOps🤨

MemOps 😃

Масштабирование развертываний Kubernetes на несколько регионов: эталонная архитектура GitOps

Эта статья описывает архитектуру, которую я бы построил, чтобы перейти от 2 до 25 регионов без страха: модель, в которой GitOps является приоритетом, где каждый регион представляет собой независимый, самовосстанавливающийся контур управления, развертывания являются декларативными коммитами, а откат — это git revert, ограниченный ровно одним регионом, — полностью изолированный от всех остальных.

📌 Подробнее: https://medium.com/@vtulasinadh/scaling-kubernetes-deployments-to-multiple-regions-a-gitops-reference-architecture-ad18a55bdaac

MemOps🤨

MemOps 😃

AI агенты в Kubernetes требуют не только изоляции, но и контроля над действиями. Обычный контейнер не гарантирует достаточной защиты. Агент может работать с секретами, обращаться к сети и выполнять недоверенный код.

В статье Isolation. Security. Scale. разбирают связку kagent и Agent Substrate для безопасного запуска агентов. Изоляция строится на двух уровнях – gVisor перехватывает системные вызовы, а microVM обеспечивает дополнительную границу на уровне виртуализации.

Отдельный акцент авторы делают на масштабировании и мультитенантности. Агенты запускаются на время активной сессии, а после её завершения освобождают ресурсы. Такой подход позволяет приблизить запуск AI агентов в Kubernetes к production-ready модели, где изоляция, политики безопасности и управление жизненным циклом работают вместе.

📌 Подробнее: https://www.cncf.io/blog/2026/10/26/isolation-security-scale/

MemOps🤨

MemOps 😃

🚨 Как один из крупнейших хостеров Рунета отстрелил себе сеть (и заодно DNS). Тотальный блэкаут Beget.

Утро понедельника для тысяч бизнесов и эникеев по всей стране началось с массового алёрта. Beget, который годами славился топовым аптаймом и ламповой поддержкой, совершил жесткое, неконтролируемое погружение на дно.

Около 2-3 ночи (МСК) у провайдера начинает сыпаться сеть. Сначала деградируют базы данных MySQL, затем отваливается панель управления, а к 8 утра легло абсолютно ВСЁ. Виртуальный хостинг, VPS, почта, панель управления, биллинг и DNS-серверы.

Саппорт открестился от хацкеров, вирусов, кинетических прилетов по ЦОДу и происков РКН:

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

Вероятнее всего это суицид SDN или фатальная ошибка маршрутизации. Кто-то глубокой ночью решил накатить небольшой патч 🎩 на автоматизацию SDN или обновить конфигурацию BGP на core-роутерах. В итоге скрипт отработал так хорошо, что маршрутизаторы отрезали сами себя и всю сеть от внешнего мира.
Удаленный доступ отвалился. Единственный способ всё починить - физически ехать в ЦОД, брать монитор + клаву + тележку, втыкаться в стойки руками и откатывать конфиги терминал за терминалом. Отсюда и отсутствие таймингов на восстановление.

Куча контор, которые держали сами сайты на сторонних дедиках в Европе или Selectel, сегодня лежат. Потому как домены они делегировали на NS-сервера Бегета. ДНС умер - маршрутизация до живых серверов остановилась ⚰️

Также мелькает инфа, что параллельно лихорадит Честный Знак. Совпадение? Когда падает инфра такого масштаба, каскадный эффект и перестроение маршрутов могут положить соседние узлы обмена трафиком.

Инженерам Beget желаю запаса кофэ, валерьянки и прямых рук 🤙

Типичный 🥸 Сисадмин

Choosing Between ClickStack and Grafana for ClickHouse Observability

Кажется, в observability снова выбор без выбора: Grafana или ClickStack?

Статья разбирает вопрос выбора на примере ClickHouse. Если ClickHouse — центральное хранилище телеметрии, а инженеры чаще расследуют инциденты, чем смотрят на заранее созданные графики, авторы предлагают смотреть в сторону ClickStack: поиск, корреляция логов, метрик и трейсов, session replay и отдельный акцент на AI/SRE-агентов через MCP.

Grafana остаётся сильнее там, где инфраструктура неоднородная: Prometheus, ClickHouse и ещё десяток источников, которые нужно собрать на одном дашборде, добавить алертинг и не заставлять команду менять привычные процессы.

Так как статья опубликована в блоге Clickhouse, практичный вывод напрашивается сам собой: «А зачем выбирать?» Grafana можно оставить для дашбордов и мониторинга, а ClickStack использовать для глубоких расследований по данным ClickHouse. Причём данные и ingestion pipeline дублировать не придётся.

📌 Подробнее: https://clickhouse.com/blog/choosing-between-clickstack-and-grafana-for-clickhouse-observability

MemOps🤨

MemOps 😃