🐧 Linux в России: Когда «суверенитет» споткнулся о ТСПУ 🚫
В отечественном IT-секторе разворачивается ситуация, граничащая с абсурдом. Уже больше недели разработчики ключевых российских ОС — Astra Linux, РЕД ОС и Alt Linux — сталкиваются с невозможностью получить обновления ядра Linux и исходные коды с официальных мировых ресурсов, таких как git.kernel.org.
В чем техническая проблема?
Судя по трассировкам и жалобам в профессиональных сообществах, пакеты «гибнут» на узлах ТСПУ (технических средств противодействия угрозам). Пытаясь задушить протоколы обхода замедления Telegram (который с 10 февраля работает в РФ с большими перебоями), регулятор применил тактику «ковровых блокировок» IP-диапазонов крупных CDN-провайдеров. Под раздачу попали зеркала Linux Kernel Archives.
Злая ирония 2026 года:
Чтобы собрать «импортонезависимое» ПО для министерств и оборонки, российские инженеры теперь вынуждены использовать VPN. То есть те самые инструменты, с которыми РКН ведет войну, стали единственным способом обновить ядро «суверенной» системы.
Команда для проверки (если у тебя тоже не тянутся апдейты):
Если твой сервер не может достучаться до репозиториев, проверь, на каком этапе обрывается связь:
Если пакеты доходят до узлов твоего провайдера и «растворяются» в пустоте — поздравляю, ты под фильтром ТСПУ.
Что делать админу прямо сейчас?
1. Зеркала: Настраивай синхронизацию через доверенные зеркала в Азии или поднимай свой локальный репозиторий внутри сети.
2. Проксирование: Если сборка встала, используй http_proxy для пакетных менеджеров (но помни про безопасность!).
3. Белые списки: Подавай заявку через ГРЧЦ на внесение ваших IP в исключения (хотя, как показывает практика этой недели, тишина в ответ — обычное дело).
Итог: Этот кейс подсветил главную уязвимость: фундамент любого российского софта — это Open Source. Пытаясь построить цифровой забор, ведомство перерезало кабель, питающий саму российскую IT-индустрию.
#linux #rkн #astralinux #редос #kernel #sysadmin #it_russia #blocking #admin_future
В отечественном IT-секторе разворачивается ситуация, граничащая с абсурдом. Уже больше недели разработчики ключевых российских ОС — Astra Linux, РЕД ОС и Alt Linux — сталкиваются с невозможностью получить обновления ядра Linux и исходные коды с официальных мировых ресурсов, таких как git.kernel.org.
В чем техническая проблема?
Судя по трассировкам и жалобам в профессиональных сообществах, пакеты «гибнут» на узлах ТСПУ (технических средств противодействия угрозам). Пытаясь задушить протоколы обхода замедления Telegram (который с 10 февраля работает в РФ с большими перебоями), регулятор применил тактику «ковровых блокировок» IP-диапазонов крупных CDN-провайдеров. Под раздачу попали зеркала Linux Kernel Archives.
Злая ирония 2026 года:
Чтобы собрать «импортонезависимое» ПО для министерств и оборонки, российские инженеры теперь вынуждены использовать VPN. То есть те самые инструменты, с которыми РКН ведет войну, стали единственным способом обновить ядро «суверенной» системы.
Команда для проверки (если у тебя тоже не тянутся апдейты):
Если твой сервер не может достучаться до репозиториев, проверь, на каком этапе обрывается связь:
# Трассировка до порта 443 (HTTPS)
mtr -T -P 443 git.kernel.org
Если пакеты доходят до узлов твоего провайдера и «растворяются» в пустоте — поздравляю, ты под фильтром ТСПУ.
Что делать админу прямо сейчас?
1. Зеркала: Настраивай синхронизацию через доверенные зеркала в Азии или поднимай свой локальный репозиторий внутри сети.
2. Проксирование: Если сборка встала, используй http_proxy для пакетных менеджеров (но помни про безопасность!).
3. Белые списки: Подавай заявку через ГРЧЦ на внесение ваших IP в исключения (хотя, как показывает практика этой недели, тишина в ответ — обычное дело).
Итог: Этот кейс подсветил главную уязвимость: фундамент любого российского софта — это Open Source. Пытаясь построить цифровой забор, ведомство перерезало кабель, питающий саму российскую IT-индустрию.
#linux #rkн #astralinux #редос #kernel #sysadmin #it_russia #blocking #admin_future
🔥4👍3🕊3
🐧 Linux: Ядро 7.0 вышло — и вот что из этого реально важно для продакшна
Коллеги, пока одни спорили о нумерации, 12 апреля 2026 года тихо вышел Linux 7.0. Сам Линус объяснил переход с 6.x: это просто сброс счётчика после того, как минорная версия добралась до 19 — никакой революции, обычный релиз на круглом номере. Но внутри есть вещи, которые прямо касаются нас.
Три изменения, за которыми стоит следить:
Первое — XFS научился самовосстанавливаться. XFS теперь может обнаруживать повреждения метаданных во время работы и исправлять их без размонтирования тома. Если вы держите XFS под базами или критическими данными — это означает меньше окон обслуживания и меньше xfs_repair в 4 утра.
Второе — Rust официально стабилен в ядре. С 7.0 снят experimental-тег с поддержки Rust, и язык теперь официально разрешён для разработки модулей ядра. Для нас как администраторов это сигнал: новые драйверы и модули безопасности будут всё чаще писаться на Rust, а значит — меньше memory corruption в сторонних модулях долгосрочно.
Третье — подписи модулей на постквантовой криптографии. Добавлена поддержка ML-DSA для аутентификации модулей ядра, а поддержка SHA-1 для подписи модулей удалена. Если у вас кастомные или DKMS-модули подписаны старыми ключами — время проверить и пересобрать.
Как проверить, что вы не сломаетесь при переходе:
Зачем это нужно:
Linux 7.0 станет ядром по умолчанию в Ubuntu 26.04 LTS и Fedora 44 — а это означает, что большинство корпоративных образов виртуальных машин через квартал-два будут именно на нём. Лучше понять изменения сейчас в лабе, чем разбираться с ними в продакшне.
Итог: XFS-самовосстановление и постквантовые подписи модулей — не хайп. Это инфраструктурные изменения, которые через год будут в каждом энтерпрайз-образе. Читайте changelog, а не только твиттер.
#linux #kernel #xfs #security #sysadmin #admin_future
Коллеги, пока одни спорили о нумерации, 12 апреля 2026 года тихо вышел Linux 7.0. Сам Линус объяснил переход с 6.x: это просто сброс счётчика после того, как минорная версия добралась до 19 — никакой революции, обычный релиз на круглом номере. Но внутри есть вещи, которые прямо касаются нас.
Три изменения, за которыми стоит следить:
Первое — XFS научился самовосстанавливаться. XFS теперь может обнаруживать повреждения метаданных во время работы и исправлять их без размонтирования тома. Если вы держите XFS под базами или критическими данными — это означает меньше окон обслуживания и меньше xfs_repair в 4 утра.
Второе — Rust официально стабилен в ядре. С 7.0 снят experimental-тег с поддержки Rust, и язык теперь официально разрешён для разработки модулей ядра. Для нас как администраторов это сигнал: новые драйверы и модули безопасности будут всё чаще писаться на Rust, а значит — меньше memory corruption в сторонних модулях долгосрочно.
Третье — подписи модулей на постквантовой криптографии. Добавлена поддержка ML-DSA для аутентификации модулей ядра, а поддержка SHA-1 для подписи модулей удалена. Если у вас кастомные или DKMS-модули подписаны старыми ключами — время проверить и пересобрать.
Как проверить, что вы не сломаетесь при переходе:
# Смотрим текущую версию и параметры компиляции
uname -r
cat /boot/config-$(uname -r) | grep -E "CONFIG_MODULE_SIG|CONFIG_RUST"
# Проверяем подписи установленных DKMS-модулей
dkms status
# Все модули должны пересобраться под новое ядро автоматически
# Для XFS — проверяем здоровье до обновления (на всякий случай)
xfs_info /dev/sda1
dmesg | grep -i xfs | grep -iE "error|corrupt|repair"
# После перехода на 7.0 — смотрим, что новый самохил XFS активен
dmesg | grep -i "xfs.*repair\|xfs.*heal"
# Ubuntu 26.04 LTS получит 7.0 из коробки (выход 23 апреля)
# На текущих системах — через mainline PPA для тестирования:
sudo add-apt-repository ppa:kernel-ppa/mainline
sudo apt update && apt list --upgradable | grep linux-image
Зачем это нужно:
Linux 7.0 станет ядром по умолчанию в Ubuntu 26.04 LTS и Fedora 44 — а это означает, что большинство корпоративных образов виртуальных машин через квартал-два будут именно на нём. Лучше понять изменения сейчас в лабе, чем разбираться с ними в продакшне.
Итог: XFS-самовосстановление и постквантовые подписи модулей — не хайп. Это инфраструктурные изменения, которые через год будут в каждом энтерпрайз-образе. Читайте changelog, а не только твиттер.
#linux #kernel #xfs #security #sysadmin #admin_future
👍1
🐧 Linux: SCHED_EXT — BPF-планировщик процессов, который меняет правила игры
Коллеги, пока все обсуждают systemd 260 и смерть SysV, в ядре тихо созревает кое-что значительно интереснее. SCHED_EXT — это extensible scheduler class для Linux, позволяющий загружать собственные планировщики CPU прямо из userspace через eBPF, без перекомпиляции ядра и перезагрузки сервера. Это не экспериментальная игрушка — это то, на что обратились инженеры из Meta, Google и NVIDIA.
Почему это важно для нас, а не только для датацентров?
Стандартный CFS (Completely Fair Scheduler) хорошо работает в среднем, но проваливается при специфических нагрузках. Нет контроля над реальными приоритетами внутри CPU, nice-значения слишком грубые. Реальтайм-классы (SCHED_FIFO, SCHED_RR) опасны — один зависший RT-процесс может заморозить систему. SCHED_EXT решает это элегантно.
Главное преимущество: BPF-верификатор гарантирует, что твой кастомный планировщик не может сломать ядро или вызвать бесконечный цикл. Если планировщик ведёт себя неправильно и задача не получает CPU дольше 30 секунд — ядро автоматически убивает BPF-планировщик и возвращает всё на CFS. Fail-safe из коробки.
Практика — запускаем готовый планировщик на продакшн-хосте:
Зачем это нужно:
BPF-планировщики можно обновлять без перезагрузки сервера — критически важно для датацентра с сотнями тысяч машин, где rolling reboot занимает недели. Но и для нашего парка из 50 серверов — возможность изолировать приоритет nginx от фоновых cronjob без правки ядра и перезагрузки стоит потраченного часа на изучение.
Итог: CFS — это справедливость для всех. SCHED_EXT — это справедливость там, где тебе нужно. Разница примерно как между светофором и круговым движением: второе умнее, но требует понимания.
#linux #ebpf #sched_ext #performance #kernel #sysadmin #admin_future
Коллеги, пока все обсуждают systemd 260 и смерть SysV, в ядре тихо созревает кое-что значительно интереснее. SCHED_EXT — это extensible scheduler class для Linux, позволяющий загружать собственные планировщики CPU прямо из userspace через eBPF, без перекомпиляции ядра и перезагрузки сервера. Это не экспериментальная игрушка — это то, на что обратились инженеры из Meta, Google и NVIDIA.
Почему это важно для нас, а не только для датацентров?
Стандартный CFS (Completely Fair Scheduler) хорошо работает в среднем, но проваливается при специфических нагрузках. Нет контроля над реальными приоритетами внутри CPU, nice-значения слишком грубые. Реальтайм-классы (SCHED_FIFO, SCHED_RR) опасны — один зависший RT-процесс может заморозить систему. SCHED_EXT решает это элегантно.
Главное преимущество: BPF-верификатор гарантирует, что твой кастомный планировщик не может сломать ядро или вызвать бесконечный цикл. Если планировщик ведёт себя неправильно и задача не получает CPU дольше 30 секунд — ядро автоматически убивает BPF-планировщик и возвращает всё на CFS. Fail-safe из коробки.
Практика — запускаем готовый планировщик на продакшн-хосте:
# Устанавливаем пакет с готовыми BPF-планировщиками
# Fedora / RHEL 10:
dnf install scx-scheds
# Ubuntu 26.04 (из репозитория):
apt install scx-scheds
# Проверяем статус SCHED_EXT в ядре
cat /sys/kernel/sched_ext/state
# disabled — нет активного планировщика, ядро использует CFS
# Запускаем scx_lavd — оптимизирован для latency-чувствительных нагрузок
# (хорошо для баз данных, веб-серверов, очередей)
sudo scx_lavd --performance &
# Проверяем что планировщик активен
cat /sys/kernel/sched_ext/state # -> enabled
cat /sys/kernel/sched_ext/root/ops # -> lavd
# Смотрим статистику планировщика в реальном времени
sudo scx_lavd --performance --stats 2
# Для тонкой настройки — scx_layered позволяет создавать слои приоритетов
# Например: критические сервисы в Layer 0, фоновые задачи в Layer 1
sudo scx_layered - << 'EOF'
[
{
"name": "critical",
"matches": [["CgroupPrefix", "system.slice/nginx"]],
"kind": {"Confined": {"cpus_pct": 60, "util_range": [0.8, 0.9]}}
},
{
"name": "background",
"matches": [["CgroupPrefix", ""]],
"kind": {"Confined": {"cpus_pct": 40, "util_range": [0.1, 0.5]}}
}
]
EOF
# Остановить планировщик — просто Ctrl+C или killall scx_lavd
# Система МГНОВЕННО падает обратно на CFS, никакого даунтайма
Зачем это нужно:
BPF-планировщики можно обновлять без перезагрузки сервера — критически важно для датацентра с сотнями тысяч машин, где rolling reboot занимает недели. Но и для нашего парка из 50 серверов — возможность изолировать приоритет nginx от фоновых cronjob без правки ядра и перезагрузки стоит потраченного часа на изучение.
Итог: CFS — это справедливость для всех. SCHED_EXT — это справедливость там, где тебе нужно. Разница примерно как между светофором и круговым движением: второе умнее, но требует понимания.
#linux #ebpf #sched_ext #performance #kernel #sysadmin #admin_future
🐧 Linux: io_uring — самый быстрый и самый опасный интерфейс ввода-вывода в ядре
Коллеги, разговор о том, что активно идёт в production прямо сейчас, но о чём мало говорят в контексте безопасности. io_uring появился в ядре 5.1 в 2019 году как революция асинхронного I/O — два кольцевых буфера между ядром и userspace, работа без системных вызовов, минимальный overhead. PostgreSQL оценивает его интеграцию, Meta использует в production годами. Производительность реальная.
Проблема тоже реальная. В июне 2023 года команда безопасности Google сообщила, что 60% эксплойтов в их bug bounty программе за 2022 год были направлены против уязвимостей io_uring. Итог: io_uring отключён в Android, полностью отключён в ChromeOS и на серверах Google.
Ситуация улучшилась, но не исчезла. io_uring может обходить системные вызовы целиком — это означает, что инструменты безопасности, основанные на перехвате syscall (Falco, Tetragon в стандартной конфигурации, многие коммерческие EDR), слепы к операциям через io_uring. Rootkit, работающий через io_uring, будет невидим для большинства систем обнаружения.
Практика: проверяем состояние io_uring в своей инфраструктуре и ограничиваем где нужно:
Зачем это нужно:
Продакшн-системы на затронутых ядрах должны иметь мониторинг таймаутов сокетных операций и исчерпания ресурсов. Критические системы могут потребовать временного отключения некоторых функций io_uring до выхода патчей. Быть слепым к части I/O-активности в продакшне в 2026 году — это не технический нюанс, это дыра в модели угроз.
Итог: io_uring — это не плохая технология. Это мощный инструмент с расширенной поверхностью атаки. Как и у любого острого инструмента — важно знать, где он лежит и кто к нему имеет доступ.
#linux #iouring #security #kernel #sysadmin #admin_future
Коллеги, разговор о том, что активно идёт в production прямо сейчас, но о чём мало говорят в контексте безопасности. io_uring появился в ядре 5.1 в 2019 году как революция асинхронного I/O — два кольцевых буфера между ядром и userspace, работа без системных вызовов, минимальный overhead. PostgreSQL оценивает его интеграцию, Meta использует в production годами. Производительность реальная.
Проблема тоже реальная. В июне 2023 года команда безопасности Google сообщила, что 60% эксплойтов в их bug bounty программе за 2022 год были направлены против уязвимостей io_uring. Итог: io_uring отключён в Android, полностью отключён в ChromeOS и на серверах Google.
Ситуация улучшилась, но не исчезла. io_uring может обходить системные вызовы целиком — это означает, что инструменты безопасности, основанные на перехвате syscall (Falco, Tetragon в стандартной конфигурации, многие коммерческие EDR), слепы к операциям через io_uring. Rootkit, работающий через io_uring, будет невидим для большинства систем обнаружения.
Практика: проверяем состояние io_uring в своей инфраструктуре и ограничиваем где нужно:
# Проверяем, используют ли процессы io_uring прямо сейчас
# Смотрим открытые io_uring файловые дескрипторы
find /proc/*/fd -type l 2>/dev/null | xargs ls -la 2>/dev/null | grep anon_inode
# Более точно — смотрим через lsof
lsof | grep io_uring
# Проверяем, какие приложения слинкованы с liburing
ldd /usr/bin/postgres 2>/dev/null | grep uring
find /usr/bin /usr/sbin /opt -type f -name "*.so*" 2>/dev/null | \
xargs grep -l "io_uring" 2>/dev/null | head -20
# ---- ОГРАНИЧЕНИЕ ДЛЯ КОНТЕЙНЕРОВ ----
# Запрет io_uring через seccomp (правильный способ для Docker/Podman)
cat > /etc/docker/seccomp-no-iouring.json << 'EOF'
{
"defaultAction": "SCMP_ACT_ALLOW",
"syscalls": [
{
"names": ["io_uring_setup", "io_uring_enter", "io_uring_register"],
"action": "SCMP_ACT_ERRNO",
"errnoRet": 38
}
]
}
EOF
# Запускаем контейнер без io_uring
docker run --security-opt seccomp=/etc/docker/seccomp-no-iouring.json nginx
# ---- ДЛЯ systemd-сервисов ----
# В unit-файле — ограничение системных вызовов
# Добавляем в [Service]:
# SystemCallFilter=~io_uring_setup io_uring_enter io_uring_register
# ---- АУДИТ ----
# Если используете auditd — добавляем правила мониторинга io_uring
cat >> /etc/audit/rules.d/iouring.rules << 'EOF'
-a always,exit -F arch=b64 -S io_uring_setup -k iouring_activity
-a always,exit -F arch=b64 -S io_uring_enter -k iouring_activity
EOF
auditctl -R /etc/audit/rules.d/iouring.rules
# Смотрим активность:
ausearch -k iouring_activity | tail -20
Зачем это нужно:
Продакшн-системы на затронутых ядрах должны иметь мониторинг таймаутов сокетных операций и исчерпания ресурсов. Критические системы могут потребовать временного отключения некоторых функций io_uring до выхода патчей. Быть слепым к части I/O-активности в продакшне в 2026 году — это не технический нюанс, это дыра в модели угроз.
Итог: io_uring — это не плохая технология. Это мощный инструмент с расширенной поверхностью атаки. Как и у любого острого инструмента — важно знать, где он лежит и кто к нему имеет доступ.
#linux #iouring #security #kernel #sysadmin #admin_future
🐧 Linux: CVE-2026-31429 — дыра в сетевом стеке ядра, патчить не откладывая
Коллеги, на прошлой неделе тихо появилась CVE-2026-31429 — уязвимость в подсистеме управления памятью сетевого стека Linux. Разбираем быстро.
Баг находится в функции skb_kfree_head() — логике освобождения памяти socket buffer. Когда включён KFENCE (Kernel Electric-Fence, дебаг-детектор памяти), функция kfence_ksize() возвращает точный запрошенный размер вместо размера slab-бакета. Это приводит к освобождению объекта в неправильный slab-кэш — classic cross-cache free.
Уязвимость находится в «горячем, активно используемом сетевом пути» — через него проходит каждый сетевой пакет. Это делает её особенно опасной несмотря на узкий технический контекст. Возможные последствия: повреждение памяти ядра, privilege escalation или kernel panic.
Зачем это нужно:
Серверы, которые не могут немедленно применить патч, должны рассмотреть ограничение сетевого доступа через firewall-правила для сокращения поверхности атаки и мониторинг журналов на предмет необычных крашей или ошибок памяти.
Итог: KFENCE по умолчанию отключён в большинстве продакшн-дистрибутивов — проверь, прежде чем паниковать. Но патч ядра в любом случае ставим при ближайшем обслуживании.
#linux #kernel #cve #security #sysadmin #admin_future
Коллеги, на прошлой неделе тихо появилась CVE-2026-31429 — уязвимость в подсистеме управления памятью сетевого стека Linux. Разбираем быстро.
Баг находится в функции skb_kfree_head() — логике освобождения памяти socket buffer. Когда включён KFENCE (Kernel Electric-Fence, дебаг-детектор памяти), функция kfence_ksize() возвращает точный запрошенный размер вместо размера slab-бакета. Это приводит к освобождению объекта в неправильный slab-кэш — classic cross-cache free.
Уязвимость находится в «горячем, активно используемом сетевом пути» — через него проходит каждый сетевой пакет. Это делает её особенно опасной несмотря на узкий технический контекст. Возможные последствия: повреждение памяти ядра, privilege escalation или kernel panic.
# Проверяем включён ли KFENCE на сервере
cat /proc/cmdline | grep -o "kfence.sample_interval=[0-9]*"
# Если вывод пустой или значение > 0 — KFENCE активен
# Проверяем версию ядра — патч уже в stable tree
uname -r
# Ubuntu: ставим обновление ядра
sudo apt update && sudo apt install --only-upgrade linux-image-$(uname -r)
sudo reboot
# RHEL/Rocky:
sudo dnf update kernel -y && sudo reboot
# Временный митигейшн пока патч не встал:
# Отключаем KFENCE через параметр загрузки
# В /etc/default/grub добавляем в GRUB_CMDLINE_LINUX:
# kfence.sample_interval=0
sudo update-grub # или grub2-mkconfig -o /boot/grub2/grub.cfg
# Дополнительно: ограничиваем доступ к BPF для непривилегированных
sysctl -w kernel.unprivileged_bpf_disabled=1
echo "kernel.unprivileged_bpf_disabled=1" >> /etc/sysctl.d/99-hardening.conf
Зачем это нужно:
Серверы, которые не могут немедленно применить патч, должны рассмотреть ограничение сетевого доступа через firewall-правила для сокращения поверхности атаки и мониторинг журналов на предмет необычных крашей или ошибок памяти.
Итог: KFENCE по умолчанию отключён в большинстве продакшн-дистрибутивов — проверь, прежде чем паниковать. Но патч ядра в любом случае ставим при ближайшем обслуживании.
#linux #kernel #cve #security #sysadmin #admin_future
🐧 Linux: CVE-2026-31431 «Copy Fail» — LPE до root из 732 байт Python-кода
Коллеги, 30 апреля опубликованы подробности уязвимости, которая затрагивает практически каждый Linux-сервер в вашей инфраструктуре. Срочно читать.
CVE-2026-31431 «Copy Fail» — локальное повышение привилегий до root для любого локального пользователя без специальных условий. Уязвимость присутствует в ядрах начиная с Linux 4.14 (2017 год). Эксплоит — 732 байта Python-кода, уже опубликован.
Проблема в authencesn — криптографическом шаблоне ядра — и эксплуатируется через интерфейс AF_ALG. Исправлена в ядрах 6.18.22, 6.19.12 и 7.0.
Действия прямо сейчас:
Зачем это важно:
Уязвимость быстро закроют в облаках и Kubernetes-кластерах. Но длинный хвост старых и забытых Linux-систем — роутеры, IoT, терминалы, промышленные системы — останется уязвимым ещё годами. В вашей инфраструктуре наверняка есть такие «забытые» хосты.
Итог: два действия сегодня — blacklist algif_aead на всех серверах где нет патча, обновить ядро там где патч доступен. PoC публичный, счёт идёт на часы.
#linux #cve #kernel #security #lpe #sysadmin #admin_future
Коллеги, 30 апреля опубликованы подробности уязвимости, которая затрагивает практически каждый Linux-сервер в вашей инфраструктуре. Срочно читать.
CVE-2026-31431 «Copy Fail» — локальное повышение привилегий до root для любого локального пользователя без специальных условий. Уязвимость присутствует в ядрах начиная с Linux 4.14 (2017 год). Эксплоит — 732 байта Python-кода, уже опубликован.
Проблема в authencesn — криптографическом шаблоне ядра — и эксплуатируется через интерфейс AF_ALG. Исправлена в ядрах 6.18.22, 6.19.12 и 7.0.
Действия прямо сейчас:
# ШАГ 1 — Проверяем версию ядра
uname -r
# Затронуты: 4.14 — 6.19.11, 6.18.0 — 6.18.21
# ШАГ 2 — Митигейшн БЕЗ перезагрузки (если патч ещё не вышел)
# Отключаем модуль algif_aead
lsmod | grep algif_aead
rmmod algif_aead 2>/dev/null || echo "Module not loaded — safe"
# Запрещаем загрузку модуля навсегда:
echo "install algif_aead /bin/false" >> /etc/modprobe.d/disable-algif-aead.conf
echo "blacklist algif_aead" >> /etc/modprobe.d/disable-algif-aead.conf
# ШАГ 3 — Обновляем ядро (для дистрибутивов с патчем)
# Ubuntu 22.04 / 24.04:
apt update && apt install --only-upgrade linux-image-generic -y
# RHEL 9 / AlmaLinux 9 / Rocky 9:
dnf update kernel -y
# Debian 12:
apt update && apt full-upgrade -y
# ШАГ 4 — Проверяем активность AF_ALG в среде
# Смотрим открытые AF_ALG сокеты
ss -a | grep ALG
# Если пусто — модуль не используется, отключение безопасно
# ШАГ 5 — Перезагружаемся после обновления ядра
# Проверяем что загрузились с новым ядром:
uname -r # должен показать исправленную версию
Зачем это важно:
Уязвимость быстро закроют в облаках и Kubernetes-кластерах. Но длинный хвост старых и забытых Linux-систем — роутеры, IoT, терминалы, промышленные системы — останется уязвимым ещё годами. В вашей инфраструктуре наверняка есть такие «забытые» хосты.
Итог: два действия сегодня — blacklist algif_aead на всех серверах где нет патча, обновить ядро там где патч доступен. PoC публичный, счёт идёт на часы.
#linux #cve #kernel #security #lpe #sysadmin #admin_future
🐧 Linux: CVE-2026-31431 «Copy Fail» — CISA добавила в KEV, дедлайн 15 мая
Коллеги, обновление по Copy Fail которую мы разбирали на прошлой неделе. 1 мая CISA официально добавила CVE-2026-31431 в каталог Known Exploited Vulnerabilities. Федеральным агентствам США предписано установить патчи до 15 мая 2026 года.
Появились новые подробности о механике атаки: эксплоит выполняет контролируемую 4-байтовую перезапись в page cache ядра, что приводит к повреждению данных. Атакующий получает UID 0 и полные root-привилегии.
Самое неприятное: поскольку page cache — это in-memory версия исполняемых файлов, его модификация фактически изменяет бинарники во время выполнения без записи на диск. Это позволяет инжектировать код в привилегированные бинарники, например /usr/bin/su, и получить root.
Для контейнерных сред угроза выше: Docker, LXC и Kubernetes предоставляют процессам внутри контейнера доступ к подсистеме AF_ALG если модуль algif_aead загружен — даже непривилегированный процесс в контейнере может эксплуатировать эту уязвимость.
Зачем это срочно: уязвимость введена тремя отдельными, каждый по себе безобидными изменениями в 2011, 2015 и 2017 годах. Она присутствует во всех дистрибутивах с 2017 года и активно эксплуатируется прямо сейчас.
Итог: патч + перезагрузка. Или blacklist algif_aead + мониторинг. Третьего варианта нет.
#linux #cve #kernel #security #copyfail #sysadmin #admin_future
Коллеги, обновление по Copy Fail которую мы разбирали на прошлой неделе. 1 мая CISA официально добавила CVE-2026-31431 в каталог Known Exploited Vulnerabilities. Федеральным агентствам США предписано установить патчи до 15 мая 2026 года.
Появились новые подробности о механике атаки: эксплоит выполняет контролируемую 4-байтовую перезапись в page cache ядра, что приводит к повреждению данных. Атакующий получает UID 0 и полные root-привилегии.
Самое неприятное: поскольку page cache — это in-memory версия исполняемых файлов, его модификация фактически изменяет бинарники во время выполнения без записи на диск. Это позволяет инжектировать код в привилегированные бинарники, например /usr/bin/su, и получить root.
Для контейнерных сред угроза выше: Docker, LXC и Kubernetes предоставляют процессам внутри контейнера доступ к подсистеме AF_ALG если модуль algif_aead загружен — даже непривилегированный процесс в контейнере может эксплуатировать эту уязвимость.
# СТАТУС ПАТЧЕЙ (по состоянию на 4 мая):
# Ubuntu 22.04: linux-image-6.5.0-44 или новее — ГОТОВ
# Ubuntu 24.04: linux-image-6.8.0-60 или новее — ГОТОВ
# RHEL/AlmaLinux/Rocky 9: kernel-5.14.0-570 или новее — ГОТОВ
# Debian 12: kernel 6.1.90 или новее — ГОТОВ
# Проверяем версию ядра:
uname -r
# Проверяем что патч применён (для Ubuntu):
apt-cache policy linux-image-$(uname -r) | grep Installed
# Если патч НЕ доступен — митигейшн:
echo "install algif_aead /bin/false" >> /etc/modprobe.d/block-algif.conf
echo "blacklist algif_aead" >> /etc/modprobe.d/block-algif.conf
# Применяется без перезагрузки:
rmmod algif_aead 2>/dev/null; echo "Module blocked"
# Проверяем контейнерные хосты — ищем загруженный модуль:
lsmod | grep algif_aead
# Если вывод пустой — хост безопасен ДО появления патча
Зачем это срочно: уязвимость введена тремя отдельными, каждый по себе безобидными изменениями в 2011, 2015 и 2017 годах. Она присутствует во всех дистрибутивах с 2017 года и активно эксплуатируется прямо сейчас.
Итог: патч + перезагрузка. Или blacklist algif_aead + мониторинг. Третьего варианта нет.
#linux #cve #kernel #security #copyfail #sysadmin #admin_future
🐧 Linux: Copy Fail — финальный статус и чего ещё не хватает в патчах
Коллеги, CVE-2026-31431 продолжает развиваться. Сегодня финальный срез по статусу — с неожиданным поворотом по RHEL.
Что случилось за неделю: Copy Fail — логический баг в криптографическом шаблоне authencesn ядра Linux. Единый 732-байтовый Python-скрипт даёт root на каждом Linux-дистрибутиве выпущенном с 2017 года. CISA добавила уязвимость в KEV с дедлайном 15 мая.
Неожиданный нюанс от Red Hat: хотя algif_aead нельзя отключить через blacklist так как он вкомпилирован в ядро, сами уязвимые функции можно заблокировать через аргументы загрузки ядра. Это меняет митигейшн для RHEL/AlmaLinux/Rocky.
Зачем это важно сегодня: в контейнерных средах Docker, LXC и Kubernetes предоставляют процессам внутри контейнера доступ к AF_ALG если algif_aead загружен на хосте. Copy Fail может использоваться для выхода из изоляции контейнера и захвата физической машины.
Итог: дедлайн CISA — 15 мая. До него восемь дней. Патч или митигейшн — прямо сейчас, не "на следующей неделе".
#linux #cve #copyfail #kernel #security #sysadmin #admin_future
Коллеги, CVE-2026-31431 продолжает развиваться. Сегодня финальный срез по статусу — с неожиданным поворотом по RHEL.
Что случилось за неделю: Copy Fail — логический баг в криптографическом шаблоне authencesn ядра Linux. Единый 732-байтовый Python-скрипт даёт root на каждом Linux-дистрибутиве выпущенном с 2017 года. CISA добавила уязвимость в KEV с дедлайном 15 мая.
Неожиданный нюанс от Red Hat: хотя algif_aead нельзя отключить через blacklist так как он вкомпилирован в ядро, сами уязвимые функции можно заблокировать через аргументы загрузки ядра. Это меняет митигейшн для RHEL/AlmaLinux/Rocky.
# СТАТУС ПАТЧЕЙ на 7 мая 2026:
# Ubuntu 22.04/24.04 → ПАТЧ ЕСТЬ: apt update && apt full-upgrade
# Debian 12 → ПАТЧ ЕСТЬ: apt update && apt full-upgrade
# AlmaLinux/Rocky 9 → ПАТЧ ЕСТЬ: dnf update kernel -y
# RHEL 9/10 → ПАТЧ ЕСТЬ (expedited): dnf update kernel -y
# Быстрая проверка везде:
rpm -q --changelog kernel | head -5 # RHEL/Rocky
apt-cache policy linux-image-$(uname -r) # Ubuntu/Debian
# МИТИГЕЙШН ДЛЯ RHEL (algif_aead вкомпилирован, не blacklistится):
# Добавляем в /etc/default/grub в GRUB_CMDLINE_LINUX:
# module_blacklist=algif_aead extra_latent_entropy
# Или через boot args напрямую:
grubby --args="module_blacklist=algif_aead" --update-kernel=ALL
grub2-mkconfig -o /boot/grub2/grub.cfg
# Перезагрузка обязательна
# Для Ubuntu/Debian — blacklist работает через modprobe:
echo "install algif_aead /bin/false" | \
tee /etc/modprobe.d/disable-algif-aead.conf
update-initramfs -u
# Проверяем Kubernetes — контейнеры тоже в зоне риска:
# Смотрим загружен ли модуль на всех нодах:
for node in $(kubectl get nodes -o name); do
echo "=== $node ==="; \
kubectl debug node/${node##*/} -it --image=alpine \
-- lsmod 2>/dev/null | grep algif_aead; \
done
Зачем это важно сегодня: в контейнерных средах Docker, LXC и Kubernetes предоставляют процессам внутри контейнера доступ к AF_ALG если algif_aead загружен на хосте. Copy Fail может использоваться для выхода из изоляции контейнера и захвата физической машины.
Итог: дедлайн CISA — 15 мая. До него восемь дней. Патч или митигейшн — прямо сейчас, не "на следующей неделе".
#linux #cve #copyfail #kernel #security #sysadmin #admin_future
🐧 Linux: Dirty Frag — вчера вечером раскрыли новый LPE, патчей ещё нет
Коллеги, срочная новость прямо с вчерашнего вечера. 8 мая независимый исследователь Хёнву Ким опубликовал Dirty Frag — два новых CVE в ядре Linux с публичным PoC и без патчей. Это не учебная тревога.
CVE-2026-43284 и CVE-2026-43500 — пара связанных уязвимостей в IPsec ESP и RxRPC подсистемах ядра. Любой непривилегированный локальный пользователь получает root. В отличие от Copy Fail с 4-байтовой записью, Dirty Frag позволяет полностью контролируемую запись в page cache в произвольном месте — за один выстрел. Исследователь сообщает о очень высокой надёжности без риска kernel panic.
Что делает это особенно опасным: контейнерные workloads наследуют уязвимость хоста — компрометация любого контейнера с доступом к AF_KEY, XFRM netlink или AF_RXRPC сокетам (дефолт для Docker, containerd и большинства Kubernetes pods) даёт root на хосте.
Embargo было нарушено третьей стороной, что вынудило исследователя опубликовать раньше срока — до выхода патчей дистрибутивов.
Зачем это критично сегодня:
Dirty Frag — прямой наследник Copy Fail того же класса уязвимостей. PoC публичен, патчей пока нет ни у одного дистрибутива. Организации должны считать уязвимость валидной и эксплуатируемой прямо сейчас.
Итог: три команды — один blacklist-файл — перезагрузка. Делай это сейчас, пока читаешь пост. Патч поставишь когда выйдет.
#linux #kernel #cve #dirtyfrag #security #lpe #sysadmin #admin_future
Коллеги, срочная новость прямо с вчерашнего вечера. 8 мая независимый исследователь Хёнву Ким опубликовал Dirty Frag — два новых CVE в ядре Linux с публичным PoC и без патчей. Это не учебная тревога.
CVE-2026-43284 и CVE-2026-43500 — пара связанных уязвимостей в IPsec ESP и RxRPC подсистемах ядра. Любой непривилегированный локальный пользователь получает root. В отличие от Copy Fail с 4-байтовой записью, Dirty Frag позволяет полностью контролируемую запись в page cache в произвольном месте — за один выстрел. Исследователь сообщает о очень высокой надёжности без риска kernel panic.
Что делает это особенно опасным: контейнерные workloads наследуют уязвимость хоста — компрометация любого контейнера с доступом к AF_KEY, XFRM netlink или AF_RXRPC сокетам (дефолт для Docker, containerd и большинства Kubernetes pods) даёт root на хосте.
Embargo было нарушено третьей стороной, что вынудило исследователя опубликовать раньше срока — до выхода патчей дистрибутивов.
# МИТИГЕЙШН — НЕМЕДЛЕННО, пока патчей нет:
# Блокируем три затронутых модуля
sudo sh -c "printf 'install esp4 /bin/false\n\
install esp6 /bin/false\ninstall rxrpc /bin/false\n' \
> /etc/modprobe.d/dirtyfrag.conf"
# Выгружаем если уже загружены:
sudo rmmod esp4 esp6 rxrpc 2>/dev/null || true
# Проверяем что модули не загружены:
lsmod | grep -E "esp4|esp6|rxrpc"
# Пустой вывод = в безопасности
# Проверяем затронуты ли конкретные версии ядра:
uname -r
# Затронуты ВСЕ дистрибутивы с ядром 2017+ до появления патча
# Следим за патчами:
# AlmaLinux: almalinux.org/blog
# Ubuntu: ubuntu.com/security/notices
# RHEL: access.redhat.com/security/vulnerabilities
# Мониторим загрузку подозрительных модулей:
auditctl -a always,exit -F arch=b64 \
-S finit_module -S init_module \
-k kernel_module_load
Зачем это критично сегодня:
Dirty Frag — прямой наследник Copy Fail того же класса уязвимостей. PoC публичен, патчей пока нет ни у одного дистрибутива. Организации должны считать уязвимость валидной и эксплуатируемой прямо сейчас.
Итог: три команды — один blacklist-файл — перезагрузка. Делай это сейчас, пока читаешь пост. Патч поставишь когда выйдет.
#linux #kernel #cve #dirtyfrag #security #lpe #sysadmin #admin_future
🐧 Linux: Killswitch в ядре — красная кнопка для zero-day, которая пугает всех кроме Red Hat
Коллеги, последние две недели — Copy Fail, Dirty Frag, оба с публичным PoC, оба до выхода патчей. Sasha Levin (NVIDIA, co-maintainer stable Linux) предложил системный ответ на этот хаос. И разгорелся нешуточный спор.
Предложенная фича «Killswitch» позволяет администраторам временно отключить конкретные уязвимые функции ядра прямо в runtime — вместо того чтобы сидеть и ждать патчей. Как сказал сам Левин: «когда уязвимость становится публичной, флоты остаются открытыми пока не будет собрано, распространено и перезагружено в новое ядро. Для многих проблем самый простой митигейшн — просто прекратить вызывать багованную функцию».
Как это работает: фича доступна через securityfs ядра. Привилегированный администратор включает killswitch для конкретной функции — она немедленно начинает возвращать ошибку. Эффект мгновенный, работает до отключения или перезагрузки.
Почему это спорно:
В r/cybersecurity предложение называют «ужасной идеей», «абсурдом» и «абсолютно пугающим». Аргумент против: люди будут использовать killswitch вместо патчинга.
Red Hat поддержал: «мы за включение killswitch в ядро, особенно по мере того как темп и серьёзность эксплойтов растёт благодаря LLM-сканированию. Патчи критичны, но они часто разрушительны. Организациям приходится взвешивать защиту через патч против производственного impact от рестартов».
Зачем это важно как концепция: killswitch — признание факта: если окно между публичным раскрытием и выходом патчей нельзя надёжно контролировать, администраторам нужен способ снизить риск на своих условиях.
Итог: proposal ещё под ревью, в ядро не принят. Но принцип — правильный. Ручная версия через blacklist работает уже сейчас и именно это большинство из нас делало последние две недели.
#linux #kernel #security #killswitch #copyfail #dirtyfrag #sysadmin #admin_future
Коллеги, последние две недели — Copy Fail, Dirty Frag, оба с публичным PoC, оба до выхода патчей. Sasha Levin (NVIDIA, co-maintainer stable Linux) предложил системный ответ на этот хаос. И разгорелся нешуточный спор.
Предложенная фича «Killswitch» позволяет администраторам временно отключить конкретные уязвимые функции ядра прямо в runtime — вместо того чтобы сидеть и ждать патчей. Как сказал сам Левин: «когда уязвимость становится публичной, флоты остаются открытыми пока не будет собрано, распространено и перезагружено в новое ядро. Для многих проблем самый простой митигейшн — просто прекратить вызывать багованную функцию».
Как это работает: фича доступна через securityfs ядра. Привилегированный администратор включает killswitch для конкретной функции — она немедленно начинает возвращать ошибку. Эффект мгновенный, работает до отключения или перезагрузки.
Почему это спорно:
В r/cybersecurity предложение называют «ужасной идеей», «абсурдом» и «абсолютно пугающим». Аргумент против: люди будут использовать killswitch вместо патчинга.
Red Hat поддержал: «мы за включение killswitch в ядро, особенно по мере того как темп и серьёзность эксплойтов растёт благодаря LLM-сканированию. Патчи критичны, но они часто разрушительны. Организациям приходится взвешивать защиту через патч против производственного impact от рестартов».
# Что это значит СЕЙЧАС — фича ещё не в ядре, это proposal.
# Но принцип уже можно применять вручную для Copy Fail и Dirty Frag:
# Copy Fail (CVE-2026-31431) — блокируем AF_ALG путь:
echo "install algif_aead /bin/false" >> /etc/modprobe.d/killswitch.conf
rmmod algif_aead 2>/dev/null
# Dirty Frag (CVE-2026-43284 + CVE-2026-43500) — блокируем esp4/esp6/rxrpc:
echo -e "install esp4 /bin/false\ninstall esp6 /bin/false\n\
install rxrpc /bin/false" >> /etc/modprobe.d/killswitch.conf
rmmod esp4 esp6 rxrpc 2>/dev/null
# Проверяем что всё заблокировано:
lsmod | grep -E "algif_aead|esp4|esp6|rxrpc"
# Пустой вывод = хорошо
# ЕСЛИ НУЖЕН esp4/esp6 (используете IPsec) — только патч ядра:
uname -r # нужна 7.0.6 / 6.18.29 / 6.12.87 / 6.6.138+
apt update && apt full-upgrade # Ubuntu/Debian
dnf update kernel -y # RHEL/AlmaLinux/Rocky
Зачем это важно как концепция: killswitch — признание факта: если окно между публичным раскрытием и выходом патчей нельзя надёжно контролировать, администраторам нужен способ снизить риск на своих условиях.
Итог: proposal ещё под ревью, в ядро не принят. Но принцип — правильный. Ручная версия через blacklist работает уже сейчас и именно это большинство из нас делало последние две недели.
#linux #kernel #security #killswitch #copyfail #dirtyfrag #sysadmin #admin_future