CVE-2026-31431 «Copy Fail»: вразливість ядра Linux

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

Body

Коротко

Публічно розкрито вразливість ядра Linux з високим впливом, що дозволяє локальне підвищення привілеїв: CVE-2026-31431, також відома як «Copy Fail».

Вразливість стосується криптографічного інтерфейсу ядра Linux, зокрема шляху algif_aead / AF_ALG. На уражених версіях ядра локальний непривілейований користувач може отримати привілеї root. Дослідники описують проблему як таку, що зачіпає основні дистрибутиви Linux з ядрами, зібраними з 2017 року, з особливим ризиком для багатокористувацьких серверів, контейнерних платформ, раннерів CI/CD і середовищ з багатьма клієнтами.

Проблема відстежується як CVE-2026-31431. Ubuntu оцінює її як High з CVSS 7.8, а Red Hat оцінює вплив як Important.

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

Що таке CVE-2026-31431?

CVE-2026-31431 є вразливістю ядра Linux у криптопідсистемі. Помилка пов’язана з некоректною операцією in-place в algif_aead, коли відображення джерела і призначення відрізняються. Виправлення в upstream-ядрі пов’язане з комітом mainline a664bf3d603d, який скасовує проблемну оптимізацію 2017 року.

Сама по собі вразливість не є віддаленою мережевою. Однак якщо зловмисник уже має локальний доступ до оболонки, доступ через скомпрометований вебзастосунок, виконання в контейнері або інший плацдарм, ця вразливість може дозволити підвищити привілеї до повного root.

Уражені операційні системи та виправлення вендорів

Вразливість може зачіпати багато дистрибутивів Linux з ядрами, зібраними з 2017 року. Стан у вендорів відрізняється залежно від дистрибутива і гілки ядра, тому правильна дія: дотримуватися офіційного бюлетеня вендора для вашої операційної системи.

1. AlmaLinux

AlmaLinux випустила виправлені ядра для підтримуваних версій. Підтверджені виправлені версії:

ОС	Виправлена версія ядра
AlmaLinux 8	kernel-4.18.0-553.121.1.el8_10 або новіша
AlmaLinux 9	kernel-5.14.0-611.49.2.el9_7 або новіша
AlmaLinux 10	kernel-6.12.0-124.52.2.el10_1 або новіша
AlmaLinux Kitten 10	kernel-6.12.0-225.el10 або новіша

Рекомендоване оновлення:

sudo dnf clean all
sudo dnf upgrade 'kernel*'
sudo reboot

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

uname -r
rpm -q kernel

2. Oracle Linux

Oracle Linux також уражена, коли працює на вразливих збірках ядра Linux. Oracle випустила оновлення безпеки Unbreakable Enterprise Kernel (UEK) для CVE-2026-31431 у межах офіційних errata Oracle Linux.

Версія Oracle Linux / гілка ядра	Виправлене ядро / рівень патча
Oracle Linux 7 / 8, UEK R6	kernel-uek-5.4.17-2136.354.4.2.el7uek / el8uek або новіша
Oracle Linux 8 / 9, UEK R7	kernel-uek-5.15.0-319.201.4.4.el8uek / el9uek або новіша
Oracle Linux 9 / 10, UEK R8	kernel-uek-6.12.0-201.74.2.2.el9uek / el10uek або новіша

Oracle позначає оновлення UEK як SECURITY, IMPORTANT, випущені 2026-05-01, і включає CVE-2026-31431 до виправлень криптопідсистеми ядра.

Рекомендоване оновлення:

sudo dnf clean all
sudo dnf update 'kernel*'
sudo reboot

Для старіших систем Oracle Linux з yum:

yum clean all
yum update 'kernel*'
reboot

Перевірка Oracle Linux

cat /etc/oracle-release
uname -r
rpm -q kernel-uek
rpm -q kernel kernel-core

Переконайтеся, що запущене ядро, яке показує uname -r, є виправленим ядром, а не лише встановленим.

3. CloudLinux

CloudLinux підтверджує, що CL7 не уражена, тоді як CL7h, CL8, CL9 і CL10 уражені. CL7h і CL8 виправляються через ядра CloudLinux, а CL9 і CL10 використовують оновлення ядра AlmaLinux.

Підтверджені цільові версії CloudLinux:

ОС	Виправлена версія ядра
CloudLinux 7	Не уражена
CloudLinux 7 Hybrid / CL7h	kernel-4.18.0-553.121.1.lve.el7h.x86_64 або новіша
CloudLinux 8	kernel-4.18.0-553.121.1.lve.el8.x86_64 або новіша
CloudLinux 9	kernel-5.14.0-611.49.2.el9_7 або новіша
CloudLinux 10	kernel-6.12.0-124.52.2.el10_1 або новіша

Рекомендоване оновлення для CloudLinux 8 / 9 / 10:

sudo dnf clean metadata
sudo dnf upgrade 'kernel*'
sudo reboot

Для старіших систем CloudLinux з yum:

yum update 'kernel*'
reboot

Перевірка:

uname -r
rpm -q kernel

Для систем з KernelCare:

kcarectl --update
kcarectl --info | grep CVE-2026-31431

CloudLinux повідомляє, що live-патчі KernelCare для багатьох уражених дистрибутивів, включно з гілками AlmaLinux, CloudLinux, Red Hat, Rocky, Oracle Linux, Ubuntu і Debian, випущені в основний канал станом на 2 травня 2026 року.

4. Ubuntu

Ubuntu опублікувала і запис у трекері CVE, і окрему публікацію в блозі щодо цієї проблеми. Ubuntu зазначає, що пом’якшення розповсюджується через пакет kmod, а виправлення вразливості розповсюджуватиметься через пакети образів ядра Linux.

Рекомендоване оновлення:

sudo apt update
sudo apt upgrade
sudo reboot

Щоб застосувати лише пакет пом’якшення, де це доречно:

sudo apt update
sudo apt install --only-upgrade kmod
sudo reboot

Перевірка:

uname -r
dpkg -l 'linux-image*' | grep ^ii
dpkg -l kmod

Щоб перевірити, чи уражений модуль наразі завантажений:

grep -qE '^algif_aead ' /proc/modules && echo "Affected module is loaded" || echo "Affected module is NOT loaded"

Ubuntu також документує ручне пом’якшення через правило modprobe.d і вивантаження algif_aead, але цей підхід підходить не всім дистрибутивам, особливо системам сімейства RHEL, де ця функціональність може бути вбудована в ядро.

5. Debian

Трекер безпеки Debian перелічує виправлені версії для кількох випусків Debian:

Випуск Debian	Виправлена версія
Bullseye security	5.10.251-3
Bookworm security	6.1.170-1
Trixie security	6.12.85-1
Forky	6.19.14-1
Sid	7.0.3-1

Рекомендоване оновлення:

sudo apt update
sudo apt upgrade
sudo reboot

Перевірка:

uname -r
dpkg -l 'linux-image*' | grep ^ii

6. Red Hat Enterprise Linux

Red Hat опублікувала бюлетень безпеки і сторінку CVE для CVE-2026-31431. Red Hat описує її як проблему криптографічного інтерфейсу ядра Linux, за якої локальний користувач може отримати привілеї root. Red Hat оцінює проблему як Important і зазначає, що виправлення випускаються через відповідні канали Red Hat.

Рекомендована дія:

sudo dnf update 'kernel*'
sudo reboot

Перевірка:

uname -r
rpm -q kernel
rpm -q kernel-core

Для систем з підпискою Red Hat також перевірте офіційну сторінку CVE Red Hat і бюлетені щодо точного виправленого пакета для вашої версії RHEL і гілки ядра.

7. SUSE

SUSE оцінює CVE-2026-31431 як important і відстежує стан за продуктом і пакетом. Деякі пакети SUSE 15 SP7 позначені як випущені, тоді як кілька гілок SUSE 16 і SUSE Linux Micro на момент перегляду ще значилися на сторінці CVE SUSE як уражені або в роботі.

Рекомендована дія:

sudo zypper refresh
sudo zypper update
sudo reboot

Перевірка:

uname -r
rpm -q kernel-default

Перевірте сторінку CVE SUSE щодо точного стану пакета для вашого продукту, сервіс-пака і варіанта ядра.

Тимчасове пом’якшення, якщо оновитися негайно неможливо

Для систем OracleLinux / AlmaLinux / CloudLinux / сімейства RHEL

Для систем сімейства RHEL безпечнішим тимчасовим пом’якшенням є додавання initcall algif_aead_init до чорного списку через командний рядок ядра з подальшим перезавантаженням:

sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
sudo reboot

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

cat /proc/cmdline | grep initcall_blacklist=algif_aead_init

або:

sudo grubby --info=ALL | grep initcall_blacklist

CloudLinux окремо попереджає, що поширене пом’якшення через modprobe.d може не спрацювати на CloudLinux, AlmaLinux чи інших системах сімейства RHEL, оскільки algif_aead може бути вбудований у ядро. У такому разі rmmod і правила modprobe.d можуть створити хибне відчуття захисту.

Після встановлення виправленого ядра тимчасове пом’якшення можна прибрати:

sudo grubby --update-kernel=ALL --remove-args="initcall_blacklist=algif_aead_init"
sudo reboot

Для систем Ubuntu / Debian

Ubuntu документує таке пом’якшення, де це доречно:

echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/manual-disable-algif_aead.conf
sudo rmmod algif_aead 2>/dev/null

Перевірка:

grep -qE '^algif_aead ' /proc/modules && echo "Affected module is loaded" || echo "Affected module is NOT loaded"

Якщо модуль не можна безпечно вивантажити, може знадобитися перезавантаження.

Посилення захисту контейнерів і Kubernetes

Для контейнерних середовищ основним виправленням залишається оновлення ядра хоста. Однак наполегливо рекомендується додаткова ізоляція.

CERT-EU рекомендує блокувати створення сокетів AF_ALG через політики seccomp для контейнерних навантажень і конвеєрів CI/CD. Docker документує seccomp як функцію ядра Linux для обмеження дій контейнерів, а стандартний профіль seccomp у Docker працює за моделлю списку дозволених.

Перевірка seccomp у Docker:

grep CONFIG_SECCOMP= /boot/config-$(uname -r)

Очікуваний результат:

CONFIG_SECCOMP=y

Запускайте контейнери зі стандартним профілем seccomp, якщо немає конкретної причини чинити інакше:

docker run --security-opt seccomp=default.json ...

Для Kubernetes використовуйте RuntimeDefault або власний профіль seccomp, де це доречно. Kubernetes підтримує застосування профілів seccomp до Pod і контейнерів, а документація Kubernetes містить інструкції із завантаження та застосування профілів.

Приклад security context у Kubernetes:

securityContext:
  seccompProfile:
    type: RuntimeDefault

Додатковий крок для серверів LiteSpeed Enterprise

Для серверів з LiteSpeed Enterprise, особливо хостингових середовищ з CloudLinux / CageFS, EuroVPS рекомендує застосувати такий додатковий крок посилення захисту LiteSpeed.

Це додаткове посилення для серверів з бінарним файлом lscgid від LiteSpeed; оновлення ядра або пом’якшення, описані вище, усе одно необхідні.

LiteSpeed позначає версію 6.3.5 як випуск із виправленнями безпеки, оптимізацією та виправленнями помилок, включно зі змінами, пов’язаними з CloudLinux CageFS. Власна документація LiteSpeed також показує, що lscgid історично використовує дозвіл setuid у звичайній роботі LiteSpeed/PHP.

Крок 2: посилення захисту бінарного файлу lscgid

Спочатку перевірте, чи встановлено LiteSpeed:

/usr/local/lsws/bin/lshttpd -v

Потім оберіть один з наведених варіантів.

Варіант A: оновлення до LiteSpeed Enterprise 6.3.5 Build 5 або новішої (рекомендовано)

Це бажаний варіант. Оновлення LiteSpeed автоматично виконує необхідне посилення дозволів lscgid:

/usr/local/lsws/admin/misc/lsup.sh -f -v 6.3.5

Після оновлення за потреби перезапустіть LiteSpeed:

/usr/local/lsws/bin/lswsctrl restart

Варіант B: швидке виправлення, якщо ви не готові оновлюватися

Якщо ви не можете оновити LiteSpeed негайно, вручну зніміть дозвіл setuid з бінарного файлу lscgid зараз:

chmod u-s /usr/local/lsws/bin/lscgid.*

Потім перезапустіть LiteSpeed:

/usr/local/lsws/bin/lswsctrl restart

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

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

1. Визначте ОС і ядро

cat /etc/os-release
uname -r

2. Перевірте встановлені пакети ядра

Системи на RPM:

rpm -q kernel
rpm -q kernel-core

Системи Debian/Ubuntu:

dpkg -l 'linux-image*' | grep ^ii

3. Підтвердьте, що запущене ядро є виправленим

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

uname -r

Порівняйте версію запущеного ядра з офіційною виправленою версією вендора для вашої ОС.

4. Підтвердьте, що пом’якшення активне, якщо воно використовується

Для систем сімейства RHEL з пом’якшенням через grubby:

cat /proc/cmdline | grep initcall_blacklist=algif_aead_init

Для модульного пом’якшення в Ubuntu/Debian:

grep -qE '^algif_aead ' /proc/modules && echo "Affected module is loaded" || echo "Affected module is NOT loaded"

5. Перевірка KernelCare

kcarectl --update
kcarectl --info | grep CVE-2026-31431

У виводі KernelCare CVE має відображатися як виправлена там, де доступний live-патч.

Важливі операційні примітки

Не запускайте публічний код proof-of-concept експлойтів на виробничих серверах.

Рекомендований план дій EuroVPS

EuroVPS рекомендує такий план дій:

1. Не обмежуйтеся патчем і перезавантаженням: застосуйте політики seccomp до контейнерних навантажень, виведіть з експлуатації операційні системи, що досягли кінця життєвого циклу, а на LiteSpeed Enterprise оновіться до 6.3.5 Build 5 або зніміть біт setuid з lscgid.

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

Якщо ви хочете, щоб наші інженери перевірили, оновили, застосували пом’якшення та верифікували ваш сервер, відкрийте тікет підтримки з особистого кабінету, вказавши ім’я хоста або IP; доступ root передавайте лише через захищене поле облікових даних тікета, ніколи в тексті тікета.

Офіційні джерела вендорів і посилання:

[1] Офіційне розкриття Copy Fail: https://copy.fail/ [2] Трекер CVE Ubuntu, CVE-2026-31431: https://ubuntu.com/security/CVE-2026-31431 [3] Блог Ubuntu, доступні виправлення вразливості Copy Fail: https://ubuntu.com/blog/copy-fail-vulnerability-fixes-available [4] Бюлетень AlmaLinux, CVE-2026-31431 Copy Fail: https://almalinux.org/blog/2026-05-01-cve-2026-31431-copy-fail/ [5] Блог CloudLinux, оновлення ядра для CVE-2026-31431 Copy Fail: https://blog.cloudlinux.com/cve-2026-31431-copy-fail-kernel-update [6] Сторінка інциденту / стану CloudLinux: https://cloudlinux.statuspage.io/incidents/642sgcmntkkk [7] Сторінка CVE Red Hat, CVE-2026-31431: https://access.redhat.com/security/cve/CVE-2026-31431 [8] Бюлетень безпеки Red Hat: https://access.redhat.com/security/vulnerabilities/RHSB-2026-02 [9] Сторінка CVE SUSE, CVE-2026-31431: https://www.suse.com/security/cve/CVE-2026-31431 [10] Трекер безпеки Debian, CVE-2026-31431: https://security-tracker.debian.org/tracker/CVE-2026-31431 [11] Документація Docker щодо seccomp: https://docs.docker.com/engine/security/seccomp/ [12] Документація Kubernetes щодо seccomp: https://kubernetes.io/docs/tutorials/security/seccomp/ [13] Oracle Linux 7 / 8, UEK R6: https://linux.oracle.com/errata/ELSA-2026-50255.html [14] Oracle Linux 8 / 9, UEK R7: https://linux.oracle.com/errata/ELSA-2026-50253.html [15] Oracle Linux 9 / 10, UEK R8: https://linux.oracle.com/errata/ELSA-2026-50254.html