🐧 Linux: CVE-2026-46333 — Qualys опубликовала четыре рабочих эксплойта. Меняем shadow.

Коллеги, вчера Qualys опубликовала полный технический разбор CVE-2026-46333 с деталями которые меняют оценку риска. Это не просто "чтение SSH-ключей" — это четыре разных вектора атаки.

Qualys построила четыре рабочих эксплойта: через chage (раскрывает /etc/shadow), ssh-keysign (раскрывает приватные host-ключи в /etc/ssh/), pkexec (выполняет произвольные команды как root), accounts-daemon (выполняет произвольные команды как root). Все подтверждены на дефолтных установках Debian 13, Ubuntu 24.04, Ubuntu 26.04, Fedora 43 и Fedora 44.

Уязвимость важна потому что современные атаки редко останавливаются на первом плацдарме. RCE работающий как www-data, скомпрометированный CI-джоб, украденный аккаунт разработчика — изначально не root. Локальный баг ядра который читает root-секреты превращает этот плацдарм в кражу учётных данных, имперсонацию хоста или lateral movement.

# ПАТЧ ЕСТЬ — проверяем прямо сейчас:
uname -r
# Патч в коммите Линуса "ptrace: slightly saner get_dumpable() logic"
# Закрыт в: 7.0.8 / 6.18.31 / 6.12.89 / 6.6.139 / 5.15.207 / 5.10.256

# Обновляем если старее:
apt update && apt full-upgrade -y && reboot   # Ubuntu/Debian
dnf update kernel -y && reboot               # RHEL/Rocky/AlmaLinux

# ЕСЛИ НА ХОСТЕ БЫЛИ ЛОКАЛЬНЫЕ ПОЛЬЗОВАТЕЛИ В МАЕ:
# 1. Ротируем SSH host keys:
rm /etc/ssh/ssh_host_*_key /etc/ssh/ssh_host_*_key.pub
ssh-keygen -A
systemctl restart sshd

# 2. Ротируем пароли учёток из /etc/shadow:
# (shadow мог быть прочитан через chage-эксплойт)
# Минимум — все системные аккаунты с shell:
awk -F: '$7 !~ /nologin|false/ && $3 >= 1000 {print $1}' \
    /etc/passwd | while read u; do passwd --expire $u; done

# 3. Митигейшн если патч ещё не применён:
echo "kernel.yama.ptrace_scope = 2" >> \
    /etc/sysctl.d/99-ptrace.conf
sysctl -p /etc/sysctl.d/99-ptrace.conf
# ptrace_scope=2: только root может ptrace непривилегированных процессов

Зачем ротировать именно shadow и SSH-ключи: в shared-hosting среде разница между раскрытием учётных данных и прямым root-доступом практически отсутствует — любого из этих файлов атакующему достаточно чтобы пройти весь оставшийся путь.

Итог: патч + перезагрузка. Если были локальные пользователи в мае — SSH host keys и пароли из shadow считай скомпрометированными. Ротация — это 10 минут работы.

#linux #cve #ssh #kernel #security #sysadmin #admin_future

🐧 Linux: LKRG 1.0 — runtime-защита ядра вышла из experimental, и вот почему это важно сейчас

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

Linux Kernel Runtime Guard (LKRG) официально достиг версии 1.0 — переход от экспериментального проекта к production-ready инструменту. После нескольких лет разработки, тестирования и реального использования релиз 1.0 сигнализирует уверенность в стабильности и долгосрочном направлении.

Что делает LKRG: это loadable kernel module который мониторит целостность ядра в runtime. LKRG выполняет runtime integrity checking ядра Linux и детектирование эксплуатации уязвимостей безопасности против ядра. Это не патч ядра — модуль, который можно собрать для широкого спектра mainline и дистрибутивных ядер без их патчинга.

Если бы LKRG стоял на серверах в мае: он бы детектировал попытки page-cache write от Copy Fail/Dirty Frag/Fragnesia и реагировал — вплоть до kernel panic или kill процесса. Это не замена патчу, но дополнительный слой.

# УСТАНОВКА:

# Rocky/AlmaLinux/RHEL (через SIG Security):
dnf install epel-release
dnf install lkrg-dkms

# Debian/Ubuntu (через Kicksecure repo):
curl -fsSL https://www.kicksecure.com/keys/derivative.asc | \
    gpg --dearmor | tee /usr/share/keyrings/derivative.asc
echo "deb [signed-by=/usr/share/keyrings/derivative.asc] \
    https://deb.kicksecure.com bookworm main" | \
    tee /etc/apt/sources.list.d/lkrg.list
apt update && apt install lkrg

# Загружаем модуль:
modprobe lkrg
dmesg | grep -i lkrg | tail -5

# Проверяем статус:
sysctl lkrg.profile_enforce
# 0=monitoring, 1=detect+log, 2=balanced, 3=heavy, 4=paranoid

# ВАЖНО: начинаем с мониторинга, не с enforce:
sysctl -w lkrg.profile_enforce=1
# Смотрим логи несколько дней — ищем false positives:
journalctl -k | grep -i lkrg | tail -20

# После проверки — включаем защиту:
echo "lkrg.profile_enforce=2" >> /etc/sysctl.d/01-lkrg.conf

# Автозагрузка:
echo "lkrg" >> /etc/modules-load.d/lkrg.conf

Важные предупреждения: performance overhead есть — около 1.7% на Intel i7, 0.1% на Ryzen. Для production-серверов это приемлемо. Опция lkrg.block_modules блокирует загрузку новых модулей — не включать если система загружает модули динамически. Начинать с profile_enforce=0 или 1 и проверять false positives несколько дней.

Итог: после мая 2026 — LKRG в production это уже не паранойя. Это разумная defence-in-depth против целого класса атак. Ставь в лабу сегодня, в прод — после тестирования.

#linux #lkrg #kernel #security #hardening #sysadmin #admin_future

🐧 Linux: CVE-2026-23111 — один лишний символ в nftables даёт root. Эксплойт публичный.

Коллеги, добрый четверг. После майского марафона LPE казалось что можно выдохнуть. Не успели.

CVE-2026-23111 сидит в коде nf_tables packet-filtering ядра и был пропатчен upstream ещё 5 февраля 2026. Exodus Intelligence выпустили полный технический разбор 8 июня, и это не первый публичный эксплойт — FuzzingLabs опубликовал независимое воспроизведение ещё в апреле. Баг свёлся к единственному лишнему символу — инвертированной проверке в nf_tables — и upstream-фикс убрал его одной строкой.

Достижимая конфигурация типична: nftables плюс unprivileged user namespaces — Linux-фича которая позволяет обычному аккаунту действовать как root внутри приватной песочницы и достигать кода ядра который иначе был бы недоступен. Оба компонента включены по умолчанию на большинстве десктопов и многих серверных сборках. Удалённого вектора нет.

Ubuntu оценивает CVSS 7.8 (high). PoC публичен с апреля.

# ПРОВЕРКА — уязвимы ли вы:
uname -r
# Патч в ядрах 7.0.6 / 6.18.28 / 6.12.87 / 6.6.138 и новее
# Если ваша версия старее — уязвимы

# Митигейшн — отключаем unprivileged user namespaces:
# (ломает некоторые приложения типа Chrome/Chromium sandbox!)
sysctl kernel.unprivileged_userns_clone
# Если 1 — включено. Отключаем:
sysctl -w kernel.unprivileged_userns_clone=0
echo "kernel.unprivileged_userns_clone=0" >> \
    /etc/sysctl.d/99-userns.conf

# Альтернатива — AppArmor restriction (Ubuntu):
# Ограничиваем user namespaces без полного отключения:
sysctl -w kernel.apparmor_restrict_unprivileged_userns=1

# Проверяем используется ли user namespaces активными процессами:
find /proc/*/ns/user -type l 2>/dev/null | wc -l
# Если > 5-10 — что-то активно использует, отключение аккуратно

# ОБНОВЛЯЕМ ЯДРО:
apt update && apt full-upgrade -y && reboot   # Ubuntu/Debian
dnf update kernel -y && reboot               # RHEL/Rocky/AlmaLinux

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

Итог: один символ в коде — root на твоём сервере. Ядро обновлено — проблемы нет. Не обновлено — mitigation через sysctl за 30 секунд.

#linux #kernel #nftables #cve #security #sysadmin #admin_future

🐧 Linux: Неделя 24 закрылась — Samba, OpenSSL и ядро требуют перезагрузки. Планируем окно.

Коллеги, добрый понедельник. После июньского рекордного хаоса на стороне Windows, в Linux-мире неделя прошла относительно спокойно — но «спокойно» не значит «можно игнорировать». Разбираем что прилетело.

Эта неделя принесла обновления ядра и core-сервисов для OpenSSL, Samba и Apache. Они почти наверняка потребуют полной перезагрузки, поэтому планируйте окно обслуживания вокруг активного продакшн-трафика. Samba-обновление имеет критический рейтинг, потому что непропатченные file-sharing сервисы исторически были самой лёгкой точкой входа для ransomware-кампаний.

И AlmaLinux, и Rocky Linux выкатывают тяжёлую пачку advisory затрагивающих ядро, BIND DNS, OpenSSL и Samba. Пропуск этих патчей оставляет сети широко открытыми для RCE и кражи данных.

Важное предупреждение по процессу: сисадмины наблюдали как продакшн-кластеры зависали после применения kernel-патчей без предварительной проверки совместимости out-of-tree модулей. .NET-обновления также раскатываются по нескольким версиям — любые backend-сервисы на этих runtime потребуют быстрого рестарта для подхвата криптографических улучшений.

# ПЕРЕД kernel-апдейтом — проверяем out-of-tree модули
# (то что зависало кластеры у других):
# Смотрим какие модули НЕ из mainline:
grep -h "" /sys/module/*/taint 2>/dev/null
# Или ищем проприетарные/внешние модули:
for mod in $(lsmod | awk 'NR>1{print $1}'); do
    modinfo "$mod" 2>/dev/null | grep -q "intree:Y" || echo "OUT-OF-TREE: $mod"
done
# Типичные виновники: nvidia, vmware, zfs, virtualbox, drbd

# Проверяем что DKMS пересоберёт их под новое ядро:
dkms status

# ПОРЯДОК БЕЗОПАСНОГО ОБНОВЛЕНИЯ:
# 1. Snapshot/backup перед апдейтом (LVM/ZFS snapshot)
# 2. Обновляем но НЕ перезагружаемся:
apt update && apt full-upgrade -y --no-install-recommends  # Debian/Ubuntu
dnf update -y                                              # RHEL/Rocky/Alma

# 3. Проверяем что DKMS-модули собрались под новое ядро:
dkms status | grep installed

# 4. Перезагружаемся в окно обслуживания:
reboot

# 5. ПОСЛЕ перезагрузки — проверяем критичные сервисы:
systemctl --failed
ss -tlnp  # слушают ли нужные порты
# Для Samba:
smbclient -L localhost -N 2>&1 | head
# Для .NET:
systemctl status <ваши-dotnet-сервисы>

Итог: неделя 24 — про дисциплину процесса, не про панику. Snapshot перед апдейтом, проверка DKMS, перезагрузка в окно, верификация сервисов после. Samba — приоритет, ransomware любит непропатченный SMB.

#linux #kernel #samba #patching #security #sysadmin #admin_future

🐧 Linux: CIFSwitch — баг 2007 года даёт root одной командой. PoC опубликован.

Коллеги, добрая среда. Шестой LPE в ядре Linux за 2026 год — и снова из той же серии что Copy Fail, Dirty Frag, Fragnesia и DirtyDecrypt. На этот раз код прятался 19 лет.

CIFSwitch (CVE-2026-46243) — локальное повышение привилегий в CIFS-подсистеме ядра Linux. Уязвимость присутствовала в коде с 2007 года — 19 лет необнаруженной. На затронутых системах любой непривилегированный локальный пользователь может получить root-shell одной командой.

Исследователь Asim Manizada раскрыл баг 28 мая 2026 с рабочим PoC на GitHub в тот же день. CVE присвоен 1 июня, пропатченные ядра дошли до production-репозиториев 2 июня.

Хорошая новость — условия эксплуатации узкие: баг находится в fs/smb/client/cifs_spnego.c — коде который обрабатывает Kerberos/SPNEGO-аутентификацию для CIFS-клиента ядра. Для эксплуатации нужны два условия: установлен cifs-utils И разрешены unprivileged user namespaces.

cifs-utils не входит в дефолтную установку большинства систем, и типичные shared-hosting серверы его не несут — такие хосты не уязвимы. Проверьте флот перед действиями.

# ШАГ 1 — Проверяем уязвимы ли мы:
# Установлен ли cifs-utils:
which mount.cifs cifs.upcall 2>/dev/null
dpkg -l cifs-utils 2>/dev/null || rpm -q cifs-utils 2>/dev/null
# Если НЕ установлен — вы НЕ уязвимы, можно выдохнуть

# Разрешены ли unprivileged user namespaces:
sysctl kernel.unprivileged_userns_clone 2>/dev/null   # Debian/Ubuntu
sysctl user.max_user_namespaces                       # RHEL/CentOS

# ШАГ 2 — Патч уже в production-репах с 2 июня:
uname -r
apt update && apt full-upgrade -y && reboot   # Debian/Ubuntu
dnf update kernel -y && reboot                # RHEL/Rocky/AlmaLinux

# ШАГ 3 — МИТИГЕЙШН без перезагрузки (если cifs не нужен):
echo "install cifs /bin/false" > /etc/modprobe.d/disable-cifs.conf
rmmod cifs 2>/dev/null
# ВНИМАНИЕ: ломает монтирование SMB/CIFS шар!

# Или удаляем cifs-utils если SMB не нужен:
apt remove cifs-utils    # Debian/Ubuntu
dnf remove cifs-utils    # RHEL/Rocky/AlmaLinux
# Без cifs-utils эксплуатация невозможна

# Или отключаем user namespaces (ломает контейнеры):
sysctl -w kernel.unprivileged_userns_clone=0  # Debian/Ubuntu
sysctl -w user.max_user_namespaces=0          # RHEL/CentOS

# ШАГ 4 — Мониторинг (multi-tenant/CI/CD):
# Следим за request_key() с необычными cifs.spnego ключами:
auditctl -a always,exit -F arch=b64 -S request_key -k cifs_spnego

Зачем это важно как тренд: 19-летний возраст уязвимого кода и наличие публичного PoC означают что эксплуатация в дикой природе вероятна. Организациям не стоит ждать подтверждённых атак перед применением митигейшна.

Итог: проверь установлен ли cifs-utils. Нет — не уязвим. Есть — патч (уже в репах) или удали cifs-utils если SMB не нужен. Шестой LPE за год — паттерн очевиден.

#linux #kernel #cifswitch #cve #security #sysadmin #admin_future

🧠 Skills: Шесть LPE за год — пора признать что патчинг это не стратегия, а тактика

Коллеги, среда — день для стратегического взгляда. CIFSwitch стал шестым LPE в ядре Linux за 2026 год: Copy Fail, Dirty Frag, Fragnesia, DirtyDecrypt, ssh-keysign-pwn и теперь CIFSwitch. Это не случайность. Это новая норма.

Паттерн каждого из них одинаков: для сисадминов управляющих Linux-флотами в 2026 году паттерн реакции один и тот же каждый раз: применить no-reboot митигейшн немедленно, затем запланировать обновление ядра и перезагрузку.

Если ты реагируешь на каждый из них вручную — ты проиграл гонку ещё до старта. Нужна стратегия defence-in-depth которая защищает ДО появления конкретной CVE.

Три слоя которые превращают "паника на каждый LPE" в "плановую работу":

СЛОЙ 1: СОКРАЩЕНИЕ ПОВЕРХНОСТИ АТАКИ (проактивно)

Большинство LPE 2026 требуют специфичных модулей/фич:
  Copy Fail    → algif_aead
  Dirty Frag   → esp4/esp6/rxrpc
  CIFSwitch    → cifs + unprivileged userns

Если этих модулей нет — ты не уязвим автоматически.
Инструмент: ModuleJail (автоблок неиспользуемых модулей)
  sudo sh modulejail -p conservative

Или вручную blacklist всего что не используется.
KDE Linux team в мае сделала именно это — вернулись к vanilla
kernel и удалили небезопасные неиспользуемые модули после аудита.

СЛОЙ 2: ОГРАНИЧЕНИЕ NAMESPACE И PTRACE (один раз настроить)

Большая часть LPE 2026 пивотится через unprivileged user namespaces:
  # Ограничиваем (ломает некоторые контейнеры — тестируй):
  sysctl -w kernel.unprivileged_userns_clone=0

Ptrace-класс (ssh-keysign-pwn):
  sysctl -w kernel.yama.ptrace_scope=1

Это закрывает не одну CVE, а целый класс векторов.

СЛОЙ 3: RUNTIME-МОНИТОРИНГ ЦЕЛОСТНОСТИ ЯДРА

LKRG (Linux Kernel Runtime Guard) — детектирует попытки
эксплуатации в реальном времени, даже неизвестных CVE:
  modprobe lkrg
  sysctl -w lkrg.profile_enforce=2

Overhead ~1.7% на Intel, 0.1% на Ryzen. Для серверов приемлемо.

ИТОГОВАЯ МАТЕМАТИКА:
  Без слоёв: каждый LPE = ручной митигейшн × N серверов = часы паники
  Со слоями: каждый LPE = "у нас этот модуль уже заблокирован" = 0 паники
              + плановый патч в обычное окно обслуживания

Один честный вопрос для среды:
Возьми CIFSwitch. Спроси себя — "если бы у меня был ModuleJail и ограниченные namespaces, был бы я уязвим к нему из коробки?" Для большинства серверов ответ — нет. cifs-utils там не стоит, namespaces ограничены. Угроза стала бы "не моя проблема" автоматически.

Зачем это важно: organizations should not wait for confirmed attacks before applying mitigations. Но ещё лучше — построить инфраструктуру где конкретная CVE уже митигирована до её раскрытия. Это разница между тактикой и стратегией.

Итог: патчинг обязателен, но это тактика. Стратегия — сокращение поверхности атаки, ограничение namespace/ptrace и runtime-мониторинг. Построй три слоя один раз — и седьмой LPE года встретишь спокойно.

#skills #security #defenseindepth #kernel #стратегия #sysadmin #admin_future

🐧 Linux: Bad Epoll — новый LPE из 2026-го, патч вышел 2 июля. Обновляемся.

Коллеги, добрый понедельник и добро пожаловать во второе полугодие. Начинаем не с отдыха — с нового LPE.

CVE-2026-46242 «Bad Epoll» — очередной локальный побег в root, опубликованный на прошлой неделе. Уязвимость затрагивает Linux-десктопы, серверы и Android-устройства, патч доступен. Параллельно Greg Kroah-Hartman анонсировал стабильные ядра 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211 и 5.10.260, включающие фикс для уязвимости в IPv6 (CVE-2026-53362), позволявшей атакующему выбраться из контейнера и получить root, и use-after-free в KVM (CVE-2026-53359), появившегося ещё в ядре 2.6.36.

Это уже восьмой по счёту публичный LPE в ядре Linux с начала года.

# Проверяем версию ядра — нужны 7.1.3 / 6.18.38 / 6.12.95+:
uname -r

# Обновляем немедленно:
apt update && apt full-upgrade -y && reboot   # Ubuntu/Debian
dnf update kernel -y && reboot               # RHEL/Rocky/AlmaLinux

# Дополнительно: CVE-2026-53362 — IPv6 container escape
# Если используете cgroups v1 (более старые среды):
cat /sys/fs/cgroup/cgroup.controllers 2>/dev/null
# Пусто = cgroups v2 (безопаснее), если есть вывод — v1 активен

# Проверяем есть ли cgroups v1 в контейнерных средах:
cat /proc/1/cgroup | head -5

# CISA также добавила CVE-2022-0492 в KEV:
# cgroup_release_agent_write() — container escape через cgroups v1
# Затрагивает ядра 2.6 - 4.20 и 5.5 - 5.17
# Если у тебя в контейнерах cgroups v1 — это активный вектор

# Принудительный переход на cgroups v2 (ломает часть legacy):
# В /etc/default/grub добавить в GRUB_CMDLINE_LINUX:
# systemd.unified_cgroup_hierarchy=1
# update-grub && reboot

# Неделя 27 — также критичные обновления для glibc и nginx:
apt-get install --only-upgrade nginx glibc-source libglib2.0-0 2>/dev/null
dnf update glibc nginx -y 2>/dev/null

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

Итог: восемь LPE за полгода — это новая реальность. Автоматизированный patch pipeline это уже не nice-to-have, это гигиена. Обновляем ядро и glibc сегодня.

#linux #kernel #cve #badepoll #lpe #security #sysadmin #admin_future

🐧 Linux: DirtyClone — невидимый LPE который не оставляет следов в логах

Коллеги, добрый вторник. Пока Bad Epoll ещё патчируется на флотах, JFrog Security Research опубликовали разбор DirtyClone (CVE-2026-43503) — и это один из самых технически изощрённых LPE в серии. CVSS 8.8.

Что делает DirtyClone особенным: атака генерирует ноль записей в kernel audit log. Ваш AIDE и Tripwire не заметят ничего — бинарь на диске не изменится. Изменится только его копия в page cache памяти. Это делает DirtyClone особенно опасным в multi-tenant средах и Kubernetes-кластерах.

Механика: баг в функции __pskb_copy_fclone() — она сбрасывает флаг SKBFL_SHARED_FRAG при клонировании сетевых пакетов. Этот флаг — маркер безопасности: "эта память файловая, не пиши в неё напрямую". Без флага ядро разрешает in-place запись. Атакующий загружает /usr/bin/su в page cache, заворачивает эти страницы в сетевой пакет, клонирует через TEE-правило netfilter, прогоняет через IPsec-туннель — и IPsec-дешифрование перезаписывает бинарь в памяти. Следующий вызов su — это уже код атакующего с root-привилегиями.

Наибольший риск несут multi-tenant облака, Kubernetes-кластеры и контейнерные workload-ы с включёнными user namespaces — любое ядро без полного patch chain CVE-2026-43503 остаётся уязвимым, даже если оригинальные DirtyFrag патчи были применены.

# ВАЖНО: это НЕ один патч — это серия из четырёх CVE
# Нужна именно полная серия для DirtyFrag + DirtyClone

# Проверяем версию ядра (нужна 7.1.3+ / 6.18.38+ / 6.12.95+):
uname -r

# Обновляем:
apt update && apt full-upgrade -y && reboot   # Debian/Ubuntu
dnf update kernel -y && reboot               # RHEL/Rocky/AlmaLinux

# МИТИГЕЙШН без перезагрузки:
# Ограничиваем user namespaces:
sysctl -w kernel.unprivileged_userns_clone=0  # Debian/Ubuntu
sysctl -w user.max_user_namespaces=0          # RHEL/Fedora

# Blacklist модулей IPsec (если не используется):
printf "install esp4 /bin/false\n\
install esp6 /bin/false\n\
install rxrpc /bin/false\n" | \
    tee /etc/modprobe.d/dirtyclone.conf
rmmod rxrpc esp4 esp6 2>/dev/null || true

# После патча — сбрасываем page cache:
echo 3 | tee /proc/sys/vm/drop_caches

# Проверяем что все четыре CVE серии закрыты:
zcat /proc/config.gz 2>/dev/null | grep CONFIG_XFRM || \
    cat /boot/config-$(uname -r) | grep CONFIG_XFRM

Итог: DirtyFrag-класс, вероятно, ещё не исчерпан — любая функция, которая перемещает fragment descriptors без сохранения shared-frag бита, является потенциальным новым CVE. Патч + перезагрузка — единственное закрытие. Остальное — стопгэп.

#linux #kernel #dirtyclone #lpe #security #контейнеры #sysadmin #admin_future

🐧 Linux: GhostLock — 15-летний баг с 97% надёжностью и цепочкой до браузера

Коллеги, добрая среда. Пока всё внимание было на июльский Patch Tuesday, на прошлой неделе Nebula Security раскрыли GhostLock (CVE-2026-43499) — и это один из самых серьёзных LPE 2026 года.

Use-after-free в подсистеме real-time mutex ядра Linux, существующий с 2011 года. Nebula добились 97% надёжности эксплойта через Google kernelCTF и получили $92,337 в рамках bug bounty. Эксплойт не только даёт root — он также позволяет выбраться из контейнера.

Но самое интересное — GhostLock является второй половиной цепочки IonStack: первая половина (CVE-2026-10702) — это уязвимость Firefox, которая выполняет код внутри браузера и выбирается из его sandbox. GhostLock несёт его дальше — до root. Одна вредоносная ссылка → root на системе.

Неприятный нюанс с патчами: оригинальный фикс привнёс отдельный краш-баг (CVE-2026-53166), и cleanup для него ещё стабилизировался в начале июля — ранние сборки могут не содержать финальную версию.

# Проверяем версию ядра — нужна актуальная с ПОЛНЫМ фиксом:
uname -r

# Ubuntu: проверяем конкретный advisory для своей версии LTS
# (Ubuntu 24.04, 22.04, 20.04 всё ещё могут быть listed as vulnerable)
ubuntu-security-status --verbose | grep -i ghostlock
# или:
apt-cache policy linux-image-$(uname -r) | grep Candidate

# Обновляем + проверяем что взяли именно финальный фикс:
apt update && apt full-upgrade -y
uname -r  # после reboot проверяем новую версию

# RHEL/Rocky/AlmaLinux:
dnf update kernel -y && reboot

# Проверяем два build flags которые усложняют эксплуатацию
# (не фикс, но mitigation):
cat /boot/config-$(uname -r) | grep -E "RANDOMIZE_KSTACK|STATIC_USERMODE"

# Приоритизация: патчить первыми shared/multi-tenant машины,
# cloud серверы, контейнерные хосты и CI-runners

Открытие GhostLock было сделано с помощью AI-инструмента VEGA от Nebula Security — автоматизированного баг-хантера. Futex priority inheritance датируется 2011 годом: старый, активно используемый код ядра, который почти никто не перечитывал годами — пока автоматизированные инструменты не начали его сканировать.

Итог: не все LPE одинаковы. GhostLock + IonStack — это браузер → root одним кликом. Это высшая лига. Проверь что взял финальный патч, а не первый фикс с краш-багом.

#linux #kernel #ghostlock #lpe #security #sysadmin #admin_future

🐧 Linux: 400+ уязвимостей ядра за 24 часа — это не апокалипсис, это AI-аудит

Коллеги, с Днём системного администратора! Сегодня праздник — но разбор горячей новости всё равно будет.

19-20 июля произошло кое-что беспрецедентное: Linux-сообщество закрыло более 400 уязвимостей ядра за 24 часа, затронув XFS, Btrfs, Netfilter, Bluetooth, KVM, NVMe, CIFS/SMB, Wi-Fi, IOMMU, DMA, RDMA и десятки сетевых драйверов. Среди них use-after-free, out-of-bounds, NULL-pointer dereferences, race conditions и improper input validation.

Это не паника. Это результат работы AI-assisted vulnerability scanning в промышленном масштабе. Торвальдс прокомментировал это прямо: ядро не является анти-AI проектом, AI — это инструмент, задача сообщества — улучшать инструменты, а не отвергать их.

Что это означает для нас как администраторов:

Снимок недели 30: glibc, ядро Linux, WebKitGTK, glib2, libtiff — всё получило критические фиксы. Apache httpd, nginx, .NET 8-10, Node.js 22, Python 3.14 — все патчатся. Отдельно стоит CVE-2026-8933 в snap-confine на Ubuntu — race condition в sandbox initialization, root code execution.

# ФИНАЛЬНЫЙ ПАТЧ-РЕЙД ИЮЛЯ — всё сразу:

# Ubuntu/Debian — максимально агрессивное обновление:
apt update && apt full-upgrade -y
# Проверяем что ядро обновилось:
uname -r
# После reboot — должна быть 7.1.4+ (вышла 23 июля):
# Linux Kernel 7.1.4 Released with Bug Fixes, Security Updates

# RHEL/Rocky/AlmaLinux — включая real-time kernel:
dnf update -y
dnf update kernel kernel-rt -y  # если используется RT-ядро

# Snap + Ubuntu — CVE-2026-8933 snap-confine:
snap refresh core
snap version

# Python 3.14 на продакшн-серверах:
python3 --version
apt install python3 --only-upgrade  # Ubuntu
dnf update python3 -y              # RHEL/Rocky

# glibc — патчится при full-upgrade, но требует reboot:
ldd --version
# Убеждаемся что взяли обновлённую версию после перезагрузки

# Audit July итог — сколько пакетов обновилось:
grep "2026-07" /var/log/dpkg.log | grep "install\|upgrade" | wc -l

Один честный тезис про 400+ CVE за сутки: это не страшнее чем 1 critical CVE с публичным PoC. Большинство из 400 — это fixes для corner cases в редко используемых драйверах без известной эксплуатации. Более сложная задача — определить какие обновления несут наибольший операционный риск. EPSS + CISA KEV — единственный рабочий фильтр.

Итог: 7.1.4 вышла 23 июля, патчи июля закрыли всё что накопилось. С Днём администратора — обнови ядро и иди отдыхать.

#linux #kernel #security #patch #sysadmin #admin_future

🐧 Skills: три CVE ядра Linux в CISA KEV — и почему «локальная» уязвимость с CVSS 9.8 должна насторожить.

Коллеги, 18 сентября CISA добавила в KEV сразу три уязвимости ядра. Red Hat 19-го подтвердил эксплуатацию и наличие публичного эксплойта. Срок для федеральных агентств — 21 сентября, всего три дня. Это нетипично мало.

ЧТО ЗАКРЫТО:
CVE-2025-39682 (9.8) — kernel TLS (модуль tls), путь приёма
CVE-2026-53266 (8.8) — ebtables SNAT, out-of-bounds write при переписывании ARP
CVE-2025-39964 (7.8) — AF_ALG, гонка при двух записях в один сокет

ФАКТ vs ИНТЕРПРЕТАЦИЯ:
Все три по описанию требуют локального доступа. CVSS 9.8 при локальном векторе — противоречие: такую оценку обычно дают сетевым багам без аутентификации. Значит, либо оценка завышена, либо вектор шире описанного. До разъяснений исходим из худшего. Практический смысл: это стадия повышения привилегий после первичного доступа — через веб-шелл, контейнер или украденный SSH-ключ.

ПРОВЕРКА:

uname -r

# Загружены ли уязвимые подсистемы
lsmod | grep -E '^(tls|ebt_snat|ebtable_nat|ebtables|af_alg|algif_[a-z]+)\s'

# Не вшиты ли в ядро (=y — блэклист не поможет, только обновление)
grep -E 'CONFIG_TLS=|CONFIG_BRIDGE_EBT_SNAT=|CONFIG_CRYPTO_USER_API' /boot/config-$(uname -r)

# Статус по дистрибутиву
# https://security-tracker.debian.org/tracker/CVE-2025-39682
apt update && apt list --upgradable 2>/dev/null | grep -E 'linux-image|proxmox-kernel'

ВРЕМЕННАЯ МЕРА (если патч прямо сейчас невозможен):

cat > /etc/modprobe.d/kev-2026-09.conf <<'EOF'
install tls /bin/false
install ebt_snat /bin/false
install algif_aead /bin/false
install algif_skcipher /bin/false
install algif_hash /bin/false
EOF

⚠️ Перед блэклистом проверить зависимости:
• kTLS используют nginx/HAProxy с ktls и часть NFS-over-TLS
• ebtables использует pve-firewall на Proxmox
• AF_ALG задействуют cryptsetup в отдельных режимах, iwd и часть криптобиблиотек
Блэклист — это мост до перезагрузки в новое ядро, а не решение.

Итог: «локальная» не значит «неважная». В KEV эти CVE попали потому, что их используют как второй шаг атаки. Обновить ядро, перезагрузиться, проверить uname -r — сегодня, если на хосте есть контейнеры, общие учётки или сервисы, доступные извне.

#skills #linux #kernel #cve #kev #proxmox #sysadmin #admin_future

🧠 Skills: Branch Target Reuse — свежий вариант Spectre v2 крадёт хеш root за 3–5 минут. Дежурный sysctl не спасёт

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

📌 ФАКТЫ (исследование VUsec + Scuola Superiore Sant'Anna)
Механика Branch Target Reuse: когда JIT-компилятор переиспользует память под новые инструкции, аппаратный предсказатель ветвлений процессора (Branch Target Buffer) продолжает помнить старые адреса ветвлений. Атакующий манипулирует спекулятивным исполнением и читает память соседних процессов.

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

PoC на Linux: непривилегированный пользователь через классический cBPF считывает хеш пароля root прямо из процесса su. Скорость утечки — около 8 байт/с (~3 минуты на ядрах Raptor Cove и ~5 минут на Lion Cove).

Идентификаторы:

CVE-2026-64507 — внедрение IBPB-flush при выделении памяти под BPF JIT.

CVE-2026-64508 — защита от JIT spraying.

Софт под ударом: затронуты не только ядра ОС, но и рантаймы: Oracle уже рандомизирует кэш кода в GraalVM, а Mozilla экстренно ужесточает изоляцию сайтов в SpiderMonkey/Firefox. Патчи для ядра Linux уже в апстриме.

⚠️ ГЛАВНЫЙ НЮАНС (почему старые рецепты не работают)
Многие админы выставляют kernel.unprivileged_bpf_disabled, будучи уверенными, что закрыли тему. Но этот параметр режет только современный eBPF.

Вектор эксплойта опирается на классический cBPF, который по умолчанию открыт любому пользователю системы через штатные сокет-фильтры (

SO_ATTACH_FILTER

).
Режим

net.core.bpf_jit_harden=2

(constant blinding) исследователи также обошли: атака замедляется, но всё равно занимает смешные 5 минут. Единственное реальное лечение — ядро с патчем.

🛠 АУДИТ ХОСТА ЧЕРЕЗ ТЕРМИНАЛ
Bash

# 1. Смотрим текущую версию ядра
uname -r

# 2. Проверяем состояние BPF и механизмов защиты
sysctl net.core.bpf_jit_enable net.core.bpf_jit_harden kernel.unprivileged_bpf_disabled

# 3. Проверяем, можно ли в теории отключить BPF JIT (если =y — флаг зашит намертво)
grep CONFIG_BPF_JIT_ALWAYS_ON /boot/config-$(uname -r)

# 4. Проверяем алгоритм хеша root в /etc/shadow:
# $y$ = yescrypt (хорошо), $6$ = SHA-512 (нормально), $1$ = MD5 (катастрофа)
awk -F: '$1=="root"{print substr($2,1,3)}' /etc/shadow

# 5. Проверяем доступность обновлений ядра в дистрибутиве
apt update && apt list --upgradable 2>/dev/null | grep -E 'linux-image|proxmox-kernel'

💡 В ЧЁМ СУТЬ И ГДЕ РЕАЛЬНЫЙ РИСК
Атака локальная, и наружу улетает хеш, а не открытый пароль.

Где риск минимален: на изолированном сервере или одиночном гипервизоре, где в консоль ходите только вы по ключам.

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

Общие терминальные Linux-серверы и VDI;

CI/CD раннеры с общим ядром (shared Docker-хосты без изоляции гипервизором);

Jump-хосты и бастионы с пулом из десятков инженеров.

Если пароль root у вас до сих пор захэширован в устаревший MD5 или сотрудники авторизуются через интерактивный su с общим паролем — вам не нужен никакой Spectre, чтобы получить инцидент.

🛡 ЧЕКЛИСТ ДЕЙСТВИЙ
Обновить ядра: в первую очередь накатить свежие сборки ядра на shared-хостах, терминалах и сборочных нодах CI/CD.

Аудит /etc/shadow: убедиться, что пароли хешируются современными функциями (yescrypt или SHA-512), а устаревшие алгоритмы выпилены из PAM.

Отказ от su: окончательно заблокировать прямой вход под root и перевести администрирование на персональные учетки с гранулярным sudo и логированием.

#skills #linux #kernel #security #spectre #cpu #bpf #cve #sysadmin #admin_future

🤖 «Мы полностью перегружены»: AI-патчи захлестнули сетевой стек Linux

Коллеги, показательная хроника из жизни ядра — тренд, который в ближайшие годы затронет каждого, кто эксплуатирует Linux-инфраструктуру.

📌 ФАКТЫ
Крик души мейнтейнера: Якуб Кичиньский (Jakub Kicinski), ключевой мейнтейнер сетевой подсистемы ядра, при отправке PR в ветку Linux 7.3 констатировал: «We are completely overwhelmed» («Мы абсолютно перегружены»).

Лавина коммитов: в цикле 7.3 в ветку net прилетело 632 патча, а в net-next — 648. По оценке мейнтейнеров, от 30% до 50% всего пула патчей в net-next сгенерированы либо отредактированы с помощью AI.

Смертный приговор легаси: весной Эндрю Ланн (Andrew Lunn) предложил радикально выпилить из ядра древние Ethernet-драйверы эпохи шин ISA/PCMCIA (старые 3Com, Xircom, чипы 8390 и др.) суммарно на ~27 600 строк кода. Причина: AI-агенты и автоматические фаззеры пачками выкапывают там гипотетические баги, слать патчи ради «галочки» легко, а реальных пользователей у этого железа уже нет.

Клин клином: запрещать нейросети не стали — ядро защищают встречным AI. Мейнтейнеры автоматизируют LLM-ревью входящих пулл-реквестов, валидацию через Patchwork и автокоррекцию commit message (бюджет на инференс frontier-моделей выделила Meta).

💡 В ЧЁМ СУТЬ ДЛЯ СИСАДМИНА

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

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

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

Внутренний саппорт ждёт то же самое: службы Helpdesk и Security-команды скоро захлебнутся во входящих баг-репортах и сканах уязвимостей, сгенерированных пользователями через локальные AI-агенты.

🛠 ДИАГНОСТИКА: КАКИЕ ДРАЙВЕРЫ ДЕРЖАТ СЕТЬ ПРЯМО СЕЙЧАС
Проверьте, какие модули ядра обслуживают ваши сетевые интерфейсы:

Bash

# 1. Физические сетевые контроллеры и активные модули ядра
lspci -k | grep -A2 -i ethernet

# 2. Быстрая привязка: сетевой интерфейс -> загруженный драйвер
for i in /sys/class/net/*; do 
  [ -e "$i/device/driver" ] && echo "$(basename "$i"): $(basename "$(readlink "$i/device/driver")")"
done

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

#linux #kernel #ai #opensource #networking #devops #sysadmin #admin_future

🔬 Google Kage: песочница для драйверов прямо внутри ядра Linux

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

📌 ФАКТЫ
Архитектура Kage: экспериментальная подсистема ядра Linux от инженеров Google, задача которой — изолировать драйверы аппаратных устройств.

Технологический фундамент: компиляторная изоляция LFI (Lightweight Fault Isolation) на базе LLVM (совместный проект Стэнфорда и Google). Драйвер продолжает исполняться в адресном пространстве ядра, но компилятор жестко ограничивает его доступ только выделенным пулом памяти, предотвращая порчу чужих структур ядра.

Рабочие прототипы: уже реализована изоляция драйверов NVMe, сетевых адаптеров и Wi-Fi стеков в рамках архитектуры VKage (интеграция с подсистемой VirtIO).

Производительность: накладные расходы заявляются значительно более низкими, чем у традиционных виртуальных песочниц и микроядерных выносов в userspace (точные бенчмарки пока не финализированы).

Готовность экосистемы: поддержка LFI для архитектуры AArch64 уже принята в апстрим LLVM, реализация под x86_64 ожидается в релизе LLVM 24. Одним из ключевых полигонов внедрения станет экосистема Android.

💡 ПОЧЕМУ ЭТО ВАЖНО СИСАДМИНУ

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

Сегодня любая ошибка адресации или use-after-free в драйвере сетевой карты либо HBA-адаптера мгновенно приводит к Kernel Panic и падению всей ноды (либо к локальному повышению привилегий). Технология Kage локализует сбой до уровня программного отказа отдельного устройства, сохраняя работу ОС и соседних сервисов.

🛠 ДИАГНОСТИКА: СТОРОННИЙ КОД В ВАШЕМ ЯДРЕ ПРЯМО СЕЙЧАС
Bash

# 1. Считаем общее число загруженных модулей ядра
lsmod | wc -l

# 2. Проверяем статус Tainted (0 = ядро чистое и стабильное, >0 = загружены проприетарные модули/были сбои)
cat /proc/sys/kernel/tainted

# 3. Выявляем модули, собранные вне основного дерева исходников ядра (out-of-tree)
for m in $(lsmod | awk 'NR>1{print $1}'); do
  modinfo -F intree "$m" 2>/dev/null | grep -q Y || echo "Вне дерева ядра: $m"
done

#linux #kernel #drivers #google #security #virtualization #sysadmin #admin_future

🧠 Skills: EXT4 объявила data=journal устаревшим. Удаление — в 2028 году. Проверьте свои маунты

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

📌 ФАКТЫ
Статус Deprecated: начиная с ядра Linux 7.3 режим монтирования data=journal в файловой системе EXT4 официально помечен как устаревший.

Таймлайн удаления: полное выпиливание кода запланировано на начало 2028 года (аккурат после стабилизации LTS-ветки 2027 года).

Что это за режим: в журнал транзакций пишутся не только метаданные файловой системы, но и само тело файлов (данные). Это давало максимальную защиту от повреждений ценой катастрофической просадки пропускной способности (двойная запись). Режим наглухо отключает Delayed Allocation и Direct I/O.

По умолчанию EXT4 работает в режиме data=ordered (журналируются только метаданные) — его эти изменения никак не затрагивают.

🛠 БЫСТРЫЙ ЧЕК СВОИХ СИСТЕМ
Bash

# 1. Смотрим, смонтировано ли что-то прямо сейчас в режиме data=journal
findmnt -t ext4 -o TARGET,SOURCE,OPTIONS | grep "data=journal"

# 2. Проверяем статическую конфигурацию в fstab
grep -n 'data=journal' /etc/fstab

# 3. Проверяем, не зашит ли режим в суперблок раздела как опция по умолчанию
for d in $(findmnt -t ext4 -no SOURCE | sort -u); do
  echo "Устройство $d:"
  tune2fs -l "$d" 2>/dev/null | grep -i 'default mount options'
done

⚠️ Если в выводе суперблока есть параметр

journal_data

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

/etc/fstab

он явно не указан!

💡 В ЧЁМ СУТЬ

Опцию

data=journal

исторически любили включать «для железобетонной надёжности» под базы данных, транзакционные логи или серверы 1С:Предприятия.

На практике за это платили колоссальным падением производительности дисковой подсистемы и деградацией SSD, получая взамен мнимую безопасность. Реальную сохранность данных дают качественные ИБП, корректная работа приложения с системным вызовом

fsync()

и регулярные проверенные бэкапы, а не костыли на уровне драйвера ФС.

Запас времени на миграцию ещё есть, но найти и перевести такие разделы в стандартный

data=ordered

лучше уже сейчас.

#skills #linux #ext4 #kernel #filesystem #storage #sysadmin #admin_future

🤖 Sashiko от Google: AI-ревьюер ядра Linux проверил 191 тысячу патчей. 463 CVE за год ссылаются на него

Коллеги, интереснейший доклад с Linux Plumbers 2026 — вторая сторона медали в истории про «лавину AI-патчей в ядре».

📌 ФАКТЫ (доклад Романа Гущина, Google)
Что такое Sashiko: открытый агентный инструмент для автоматизированного ревью патчей ядра Linux, работающий в связке с моделями Gemini и другими LLM.

Масштаб работы менее чем за год:

191 000+ проведённых код-ревью в 99 официальных списках рассылки (LKML и подсистемы);

19 млн+ автоматизированных обращений к Git-дереву;

7 600+ ответов от 1 100+ живых разработчиков ядра на замечания и баг-репорты Sashiko;

1 277 коммитов в апстрим основного ядра и 1 567 в ветку linux-next содержат прямые ссылки на отчёты инструмента;

463 CVE ядра Linux, выпущенных в этом году, напрямую цитируют выводы Sashiko.

Роадмап проекта: запуск локального CLI-режима для проверки кода из терминала разработчика, формирование постоянной базы найденных багов и пре-ревью собственных коммитов.

💡 В ЧЁМ СУТЬ ДЛЯ СИСАДМИНА

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

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

Концепция «обновляем ядро раз в два года, когда совсем прижмёт» окончательно устарела: патч-менеджмент ядра должен быть регулярным и плановым процессом.

🛠 БЫСТРЫЙ ЧЕК СЕРВЕРА: НА СКОЛЬКО СВЕЖЕМ ЯДРЕ ВЫ ЖИВЁТЕ
Bash

# 1. Текущая активная версия ядра и время с последнего ребута ноды
uname -r; uptime -s

# 2. Проверяем, есть ли в /boot ядро новее работающего (Debian / Ubuntu)
ls -t /boot/vmlinuz-* 2>/dev/null | head -1

# 3. Висит ли флаг обязательной перезагрузки после обновлений пакетов
[ -f /var/run/reboot-required ] && cat /var/run/reboot-required

#linux #kernel #ai #google #opensource #cve #security #sysadmin #admin_future

🤖 Линус Торвальдс пишет патч для ядра с Claude Code. И честно это указывает

Коллеги, интересное из жизни ядра — без хайпа и строго по фактам.

📌 ФАКТЫ
Ветка в репозитории: в персональном Git-дереве Торвальдса появилась ветка noref-filemap-read-with-llm.

Архитектурная суть: оптимизация сценария, когда множество параллельных потоков одновременно читают один и тот же файл небольшими порциями. Чтение из Page Cache переводится в режим без инкремента счётчика ссылок на folio (page refcount contention). Именно постоянное атомарное обновление счётчика ссылок создаёт узкое горлышко и конкуренцию на кэш-линиях CPU при интенсивном параллельном I/O.

Честный commit message: в описании патча Линус прямо зафиксировал, что изменения подготовлены «LLM-ассистентом (Claude Code) под моим руководством». Модель помогла со скелетом кода, синтетическими тестовыми программами, перекрёстным ревью и черновиком сопроводительного письма.

Верификация: все бенчмарки и профилирование Торвальдс проводил лично на своём рабочем железе. Патчи ещё не влиты в апстрим, вероятная цель — окно слияния Linux 7.4.

Индустриальный контекст: одновременно с этим NVIDIA представила Boro — локальный AI-инструмент, заточенный под разработку и верификацию кода ядра на языке Rust.

💡 В ЧЁМ СУТЬ ДЛЯ СИСАДМИНА

Важен не сам факт задействования нейросетей, а культура инженерной ответственности:

Архитектурную постановку задачи, контроль логики и валидацию замеров выполняет живой сеньор-инженер. Факт использования ассистента декларируется открыто, а персональная ответственность за продакшен-код остаётся на авторе коммита.

Ровно по этой модели должна строиться эксплуатация любого AI-инструмента в инфраструктуре: генерировать скрипт или конфиг может модель, но валидирует, пушит в прод и несёт ответственность только сисадмин.

При принятии коммитов прямую выгоду по I/O получат высоконагруженные веб-серверы (Nginx/Envoy, отдающие статику), ноды контейнеризации с общими read-only слоями образов и CI/CD сборочные фермы.

#linux #kernel #ai #torvalds #opensource #performance #sysadmin #admin_future

🐧 Linux 7.3 вышел — вероятная LTS-версия. Что в нём полезного для серверов

Коллеги, 18 октября Линус Торвальдс представил релиз ядра Linux 7.3. По традиции осенних релизов ожидается, что именно эта ветка получит статус долгосрочной поддержки (LTS).

📌 КЛЮЧЕВЫЕ ИЗМЕНЕНИЯ ДЛЯ СЕРВЕРОВ
Хранилища и ФС:

Оптимизирована параллельная прямая запись (direct I/O) и системный вызов fallocate() в ext4.

Ускорены мелкоблочные direct-чтения в ext4 и XFS: в синтетических тестах Bytedance на пуле быстрых NVMe Gen5 зафиксирован рост с 1,92 до 2,19 млн IOPS.

Время выполнения fsync в Btrfs сокращено до 5 раз в сценариях с частой фиксацией метаданных.

Планировщик CPU: переработан механизм распределения процессорного времени внутри cgroup для предотвращения «залипания» интерактивных и высокоприоритетных задач под тяжелым фоновым троттлингом. Новый сбалансированный режим concur включен по умолчанию (доступен откат к legacy-поведению).

Сетевой стек: поддержка Big TCP расширена на оверлейные туннели VXLAN и GENEVE — критично для высоконагруженных SDN-фабрик и оверлейных сетей Kubernetes/OpenStack (снижение оверхеда на обработку пакетов при 100G+ линках).

Виртуализация: гипервизор KVM научился эффективно детектировать и маркировать «холодную» (неиспользуемую) память гостевых ВМ для прозрачного освобождения хостовых страниц.

Файловый доступ: модуль ядра ksmbd получил нативную поддержку расширений для резервного копирования Apple Time Machine по SMB.

Низкоуровневый ввод-вывод: флаг RWF_DONTCACHE адаптирован для прямых операций с блочными устройствами; добавлены буферные пулы и поддержка zero-copy для FUSE через интерфейс io_uring.

Устаревание: режим монтирования data=journal в ext4 официально помечен как deprecated (полное удаление запланировано на 2028 год).

🛠 СРОКИ ПОЯВЛЕНИЯ В ДИСТРИБУТИВАХ
Ubuntu 26.10: релизный апдейт ядра прилетит через стандартные репозитории в ближайшие недели (стартовала с -rc6).

Ubuntu 26.04 LTS: через стек HWE (Hardware Enablement) в начале 2027 года.

Debian и Proxmox VE: по графику включения в тестовые и стабильные ветки (ветка Proxmox 9).

Bash

# Проверка текущего запущенного ядра на хосте
uname -r

💡 В ЧЁМ СУТЬ

Если 7.3 окончательно утвердят в качестве долгосрочной LTS-ветки, именно это ядро станет фундаментом для корпоративных дистрибутивов и гипервизоров на ближайшие несколько лет.

На хостах с высокой плотностью контейнеров (LXC, Docker, K8s) обратите особое внимание на поведение нового cgroup-планировщика под пиковой нагрузкой — распределение CPU-квот может стать заметно более агрессивным к фоновым воркерам.

#linux #kernel #lts #storage #performance #sysadmin #admin_future

📨 Уязвимости ядра Linux по ошибке попали в публичную рассылку. Две из них — RCE с CVSS 9.0 в SMB-коде ядра

Коллеги, история, которая напрямую касается ваших файловых серверов на Linux.

📌 ФАКТЫ
22 октября Zero Day Initiative (Trend Micro) отправила отчёты о шести уязвимостях не в закрытый список безопасности ядра, а в публичную LKML. Судя по всему, по ошибке

Самые серьёзные — удалённое выполнение кода с CVSS 9.0 в SMB Direct и во встроенном SMB-сервере ядра ksmbd

Остальные — повышение привилегий (сетевой код, драйвер VMware vmwgfx и др.) и утечка информации (NVMe target)

На момент публикации исправлений в основном ядре нет: для части уже готовятся патчи

🛠 ЗАДЕВАЕТ ЛИ ВАС
Bash

# ksmbd — модуль ядра, не путать с обычной Samba (smbd)
lsmod | grep -E 'ksmbd|smbdirect'
systemctl status ksmbd 2>/dev/null | head -3

# Кто слушает 445 порт
ss -ltnp | grep ':445'

Пусто или процесс smbd — у вас классическая Samba, ksmbd не используется

Если ksmbd включён и не нужен — выгрузите модуль и запретите его загрузку до выхода патчей

Bash

modprobe -r ksmbd
echo 'install ksmbd /bin/false' > /etc/modprobe.d/disable-ksmbd.conf

💡 В ЧЁМ СУТЬ

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

#linux #kernel #smb #ksmbd #security #sysadmin #admin_future

🦀 Из ядра Linux удалили драйвер на C — его полностью заменила версия на Rust. Впервые для кода, работающего на миллиардах устройств

Коллеги, исторический рубеж в разработке ядра Linux 7.4.

📌 ФАКТЫ
В ветке Linux 7.4 окончательно удалена C-реализация IPC-драйвера Binder от Google — ключевого механизма межпроцессного взаимодействия, на котором построена вся архитектура Android

Единственной и основной реализацией становится Binder на Rust

Мейнтейнер стабильной ветки Грег Кроа-Хартман (Greg Kroah-Hartman) в мерж-реквесте отметил: «Удаление C-кода Binder: версия на Rust показала стабильность и будет использоваться дальше на миллиардах устройств»

Инженеры Google неоднократно подчёркивали, что поддержка и рефакторинг исходного кода на C с ручным управлением ресурсами и блокировками стали «болезненными в сопровождении» и источником постоянных гонок данных

📊 ТРЕНД ЗА ОКТЯБРЬ В КАНАЛЕ
Дистрибутив Ubuntu 26.10 полностью завершил миграцию базовых утилит на Rust coreutils (uutils)

Проект systemd официально разрешил разработку сервисных компонентов на Rust (пилотный systemd-keyring-setup)

В релиз ядра Linux 7.4 суммарно влито свыше 17 тыс. строк инфраструктуры и драйверов на Rust

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

🛠 АУДИТ ПОДДЕРЖКИ RUST В ТЕКУЩЕМ ЯДРЕ
Bash

# Проверяем флаг сборки подсистемы Rust в рабочем ядре
grep -E '^CONFIG_RUST=' /boot/config-$(uname -r) 2>/dev/null || echo "Rust не включён"

💡 В ЧЁМ СУТЬ

До этого момента присутствие Rust в апстриме ядра воспринималось как осторожный эксперимент «в песочнице» рядом с неприкасаемым кодом на C.

Полный снос старого C-драйвера, обеспечивающего работу миллиардов Android-устройств, меняет статус Rust: это больше не факультатив, а production-ready стандарт для критических узлов. Для серверной инфраструктуры в долгосрочной перспективе это закрывает целый пласт kernel-level уязвимостей классов use-after-free, double free и гонок за память.

#linux #kernel #rust #android #opensource #sysadmin #admin_future