Dirty Frag: вразливість ядра Linux і як її виправити
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
Почнімо з вашої інфраструктури.
Трохи контексту допомагає нам почати правильну розмову.
