Перейти до вмісту
EuroVPSEuroVPS

Dirty Frag: вразливість ядра Linux і як її виправити

FAQ EuroVPS

Оновлено 5 хв читання

Shared FAQ page chrome (breadcrumb, dates, read time, «Читайте далі», enquiry block, category labels): see INDEX-AND-CHROME.md. Translate once.

Body

Останнє оновлення: 9 травня 2026 року

Коротко

Розкрито вразливість ядра Linux, що дозволяє локальне підвищення привілеїв, відому як Dirty Frag. Вона відстежується переважно як:

  • CVE-2026-43284: IPsec ESP / esp4 / esp6
  • CVE-2026-43500: RxRPC / rxrpc

Dirty Frag може дозволити локальному непривілейованому користувачу отримати привілеї root. Це не прямий віддалений мережевий експлойт, але він серйозний для хостингових серверів, оскільки зловмисник спочатку може отримати обмежений доступ через скомпрометований вебсайт, обліковий запис SSH/SFTP, контейнерне навантаження або локальний обліковий запис користувача. cPanel підтверджує, що проблема зачіпає саме ядро Linux і присутня в багатьох дистрибутивах Linux. (cPanel Support)

Уражені системи

Dirty Frag зачіпає багато дистрибутивів Linux і гілок ядра. Підтверджено уражені платформи:

  • AlmaLinux 8, 9, 10
  • Rocky Linux 8, 9, 10
  • CloudLinux 7 Hybrid, 8, 9, 10
  • Red Hat Enterprise Linux 8, 9, 10
  • Ubuntu 20.04, 22.04, 24.04 та інші підтримувані випуски Ubuntu
  • Системи Oracle Linux з ураженими ядрами RHCK або UEK
  • Інші дистрибутиви Linux з ураженими версіями ядра

CloudLinux підтверджує, що стандартна CloudLinux 7 не уражена, тоді як CloudLinux 7 Hybrid, 8, 9 і 10 уражені. CloudLinux 9 і 10 використовують гілку ядра AlmaLinux. (CloudLinux Blog)

Необхідні дії

Рекомендоване виправлення: встановити виправлене вендором ядро і перезавантажити сервер.

Перевірте поточне ядро:

uname -r

Після оновлення та перезавантаження перевірте знову:

uname -r

Самого лише встановлення пакета ядра недостатньо. Сервер має завантажитися у виправлене ядро.

Інструкції з оновлення за ОС

AlmaLinux 8 / 9 / 10

Оновіть ядро:

dnf clean metadata
dnf update 'kernel*' -y
reboot

Перевірка:

uname -r
rpm -q kernel

Очікувані виправлені версії:

AlmaLinux 8:  kernel-4.18.0-553.123.2.el8_10 or newer
AlmaLinux 9:  kernel-5.14.0-611.54.3.el9_7 or newer
AlmaLinux 10: kernel-6.12.0-124.55.2.el10_1 or newer

AlmaLinux підтверджує ці виправлені версії ядра у своєму бюлетені щодо Dirty Frag. (AlmaLinux OS)

CloudLinux

CloudLinux 7 Hybrid / 8

Якщо виправлене ядро доступне в стабільних репозиторіях:

yum update 'kernel*' -y
reboot
uname -r

Якщо виправлене ядро доступне лише в тестовому/бета-репозиторії:

Для CloudLinux 8:

yum --enablerepo=cloudlinux-updates-testing update 'kernel*' -y
reboot
uname -r

Для CloudLinux 7 Hybrid:

yum --enablerepo=cl7h_beta update 'kernel*' -y
reboot
uname -r

Очікувані виправлені версії:

CloudLinux 7 Hybrid: kernel-4.18.0-553.123.2.lve.el7h or newer
CloudLinux 8:        kernel-4.18.0-553.123.2.lve.el8 or newer

CloudLinux наводить ці цільові версії для виправлених гілок ядра CL7h і CL8. (CloudLinux Blog)

CloudLinux 9 / 10

CloudLinux 9 і 10 використовують гілку ядра AlmaLinux. Якщо виправлене ядро доступне зі стабільних репозиторіїв:

dnf update 'kernel*' -y
reboot
uname -r

Очікувані виправлені версії:

CloudLinux 9:  kernel-5.14.0-611.54.3.el9_7 or newer
CloudLinux 10: kernel-6.12.0-124.55.2.el10_1 or newer

Якщо виправлене ядро ще не видно зі стабільних репозиторіїв або локальних дзеркал, тимчасово скористайтеся тестовим репозиторієм AlmaLinux.

Для CloudLinux 10:

dnf install -y https://repo.almalinux.org/almalinux/10/extras/x86_64/os/Packages/almalinux-release-testing-10-1.el10.x86_64.rpm
dnf update 'kernel*' -y
reboot

Після перезавантаження:

uname -r
dnf config-manager --disable almalinux-testing

Для CloudLinux 9:

dnf install -y https://repo.almalinux.org/almalinux/9/extras/x86_64/os/Packages/almalinux-release-testing-9-1.el9.noarch.rpm
dnf update 'kernel*' -y
reboot

Після перезавантаження:

uname -r
dnf config-manager --disable almalinux-testing

Використовуйте тестовий репозиторій лише для оновлення пакетів ядра і вимкніть його одразу після перевірки. CloudLinux документує цей тимчасовий процес з тестовим репозиторієм для CL9 і CL10. (CloudLinux Blog)

RHEL / Rocky Linux / Oracle Linux

Для систем сімейства RHEL:

dnf clean all
dnf update 'kernel*' -y
reboot

Для систем Oracle Linux з UEK також оновіть пакети UEK:

dnf update 'kernel*' 'kernel-uek*' -y
reboot

Перевірка:

uname -r
rpm -q kernel kernel-core kernel-uek 2>/dev/null

Red Hat підтверджує, що Dirty Frag зачіпає RHEL 8, 9, 10 і OpenShift 4, і рекомендує оновлення ядра або пом’якшення залежно від доступності патчів. (Red Hat Customer Portal)

Ubuntu / Debian

Оновіть ядро системи:

apt update
apt full-upgrade -y
reboot

Перевірка:

uname -r
dpkg -l | grep linux-image

Ubuntu підтверджує, що виправлення постачається через пакети образів ядра Linux, і рекомендує перезавантажитися в оновлене ядро. (Ubuntu)

SUSE / openSUSE

Оновіть ядро:

zypper refresh
zypper update kernel-default
reboot

Перевірка:

uname -r
rpm -qa | grep kernel

Тимчасове пом’якшення

Якщо виправлене ядро або live-патч ще недоступні, заблокуйте уражені модулі:

cat > /etc/modprobe.d/dirtyfrag.conf <<'EOF'
install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
EOF

rmmod esp4 esp6 rxrpc 2>/dev/null || true

Перевірка:

grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"

Це пом’якшення блокує esp4, esp6 і rxrpc, тобто уражені шляхи модулів ядра. CloudLinux, Ubuntu і Red Hat документують цей підхід блокування модулів як тимчасове пом’якшення. (CloudLinux Blog)

Важливе попередження

Не застосовуйте це пом’якшення без перевірки на системах, що використовують:

  • IPsec
  • StrongSwan
  • Libreswan
  • VPN-шлюзи
  • навантаження AFS / RxRPC

Блокування esp4 і esp6 може порушити трафік IPsec, а блокування rxrpc може вплинути на навантаження AFS/RxRPC. Ubuntu і Red Hat відзначають цей операційний вплив. (Ubuntu)

Додатковий крок для Ubuntu / Debian

На системах Ubuntu і Debian після застосування пом’якшення перегенеруйте initramfs:

update-initramfs -u -k all

Потім перевірте знову:

grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"

Ubuntu рекомендує перегенерувати initramfs, щоб уражені модулі залишалися заблокованими під час завантаження. (Ubuntu)

Скидання сторінкового кешу після пом’якшення

Після застосування пом’якшення скиньте сторінковий кеш:

sync
echo 3 > /proc/sys/vm/drop_caches

CloudLinux зазначає, що експлойт може змінювати легітимні системні бінарні файли в сторінковому кеші, тому після пом’якшення на потенційно атакованих системах рекомендується скинути сторінковий кеш. (CloudLinux Blog)

Зняття пом’якшення після встановлення патча

Після встановлення виправленого ядра і перезавантаження сервера в нього:

rm -f /etc/modprobe.d/dirtyfrag.conf

Для Ubuntu / Debian:

update-initramfs -u -k all

За потреби перезавантажте:

reboot

KernelCare

Якщо встановлено KernelCare:

kcarectl --update

Перевірте покриття:

kcarectl --patch-info | grep -E 'CVE-2026-43284|CVE-2026-43500|Dirty Frag'

Якщо CVE не з’являється у виводі, KernelCare може ще не покривати запущене ядро. У такому разі застосуйте оновлення ядра від вендора або тимчасове пом’якшення. cPanel і CloudLinux посилаються на KernelCare як на доступний шлях live-патчів там, де є покриття. (cPanel Support)

Чекліст перевірки

Виконайте після встановлення патча або пом’якшення:

cat /etc/os-release
uname -r

Для систем сімейства RHEL:

rpm -q kernel kernel-core kernel-uek 2>/dev/null

Для Ubuntu / Debian:

dpkg -l | grep linux-image

Перевірте уражені модулі:

lsmod | grep -E 'esp4|esp6|rxrpc'

Підтвердьте стан пом’якшення:

grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"

Рекомендація EuroVPS

Обмежте непотрібний доступ по SSH, SFTP, до оболонки та панелі, перевірте сервер на скомпрометовані вебсайти, неочікуваних локальних користувачів або підвищення привілеїв, і перенесіть операційні системи, що досягли кінця життєвого циклу.

Потрібна допомога?

Відкрийте тікет підтримки з особистого кабінету, і на серверах, до яких ми маємо доступ root, наші інженери встановлять патч або застосують пом’якшення та перевірять виправлення.

З FAQ EuroVPS, уперше опубліковано 8 травня 2026 р..

Більше в категорії «Оголошення»

Ваш наступний партнер з інфраструктури

Залишилося
запитання?

Розкажіть, що ви намагаєтеся зробити. Інженер прочитає і відповість.

+357 222 32280
Інженер EuroVPS несе серверний вузол у залі дата-центру
Розмова з людьми, які доглядатимуть за вашою інфраструктурою.

Почнімо з вашої інфраструктури.

Трохи контексту допомагає нам почати правильну розмову.

Ми використаємо ваші дані, щоб відповісти на ваш запит. Політика конфіденційності