Docker Engine і Copy Fail: що оновити, якщо kernel patch ще не доїхав

Зачіпка

Docker інколи виглядає як ще один шар у стеку, який просто треба тримати в актуальному стані. Але з Copy Fail це стало дуже приземленою історією: якщо на хості ще немає kernel patch, саме Docker Engine може дати вам швидке тимчасове зниження ризику, поки дистрибутив не випустив виправлення.

Це не про “все зламалося”. Це про те, що на Linux-хостах із контейнерами є вузьке, але реальне вікно ризику. Docker 27 травня 2026 року описав CVE-2026-31431 як проблему ядра Linux і окремо пояснив, що старі default profiles Docker Engine дозволяли контейнерам відкривати AF_ALG sockets, через які і працює експлойт. Тобто сам Docker не є коренем проблеми, але він був одним із місць, де можна швидко зменшити exposure.

Що саме сталося

CVE-2026-31431, який ще називають Copy Fail, це вразливість у Linux kernel, пов’язана з AF_ALG crypto subsystem. Якщо говорити просто, атакувальник, який уже виконав код всередині контейнера, може через цей шлях впливати на page cache. А page cache спільний для всього хоста.

Саме тут і є небезпека: це не тільки проблема “одного поганого контейнера”. Якщо сторінки в кеші змінені, наслідки можуть зачепити інші процеси на тому ж хості, інші контейнери і навіть shared image layers. Це вже не локальна дрібниця, а ризик для всього вузла.

Docker у своєму розборі прямо каже головну річ: правильний fix це kernel update. Усе інше лише зменшує exposure на час, поки патч ще не прилетів від вашого дистрибутива.

Чому це важливо саме для ops-команди

Для звичайного користувача це звучить як ще одна CVE. Для людини, яка тримає прод або staging на Docker-хості, це означає зовсім інше:

• якщо kernel ще не оновлений, контейнерні обмеження стають частиною оборони;
• якщо Docker Engine старий, ви втрачаєте один із швидких способів знизити ризик;
• якщо ви намагаєтеся “швидко полагодити” все через seccomp=unconfined, ви просто відкриваєте більше, ніж хотіли.

У release notes Docker видно всю еволюцію фікса. У 29.4.2 команда заблокувала AF_ALG sockets і socketcall(2) через seccomp, але це зламало частину 32-bit workloads та i386 images. У 29.4.3 вони прибрали надто широкий socketcall deny і перенесли захист на AppArmor та SELinux, щоб закрити і socket(2), і socketcall(2) без поломки легітимних 32-bit сценаріїв.

Що робити сьогодні

1. Перевірте, чи ви взагалі під ризиком

На хості подивіться версію ядра і версію Docker:

uname -r
docker version
docker info

Якщо kernel вже має патч від вашого дистрибутива, це найкращий шлях. Якщо ні, рухайтеся далі без паніки, але й без затягування.

2. Спершу оновіть kernel

Це реальний fix. Docker у блозі прямо пише, що mitigation в Engine не замінює kernel patch. Якщо ваш vendor уже випустив оновлення ядра, ставте його першим кроком.

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

3. Потім оновіть Docker Engine до 29.4.3 або новішого

Саме ця версія повернула баланс між безпекою і сумісністю. Вона:

• закриває AF_ALG через AppArmor / SELinux;
• залишає seccomp як додатковий захист;
• не ламає 32-bit workloads так, як це робила попередня спроба.

На SELinux-хостах є окремий нюанс: потрібен selinux-enabled: true у daemon.json або через CLI flag. Без цього SELinux-mitigation не працюватиме так, як очікується.

4. Якщо оновити kernel або Engine прямо зараз не виходить

Тут не треба вигадувати магію. У Docker release notes є легальні тимчасові варіанти:

• для окремих контейнерів можна використати кастомний seccomp profile;
• у 29.4.2 Docker радив seccomp/v0.2.1, який блокує AF_ALG, але повертає socketcall для сумісності;
• не використовуйте --security-opt seccomp=unconfined як “швидкий обхід” — це не лікує проблему, а просто прибирає ще один бар’єр.

Якщо у вас є 32-bit застосунки або старі образи, перевірте їх окремо. Саме там найчастіше з’являються сюрпризи.

5. Перезапустіть Docker daemon і перевірте, що зміна застосувалася

Після оновлення Engine зазвичай достатньо restart daemon, без повного reboot хоста. Але якщо ви міняли AppArmor профілі або SELinux-параметри, перевірка після зміни обов’язкова.

Корисний мінімальний чек:

docker run --rm alpine uname -a
docker run --rm alpine sh -lc 'id && cat /etc/os-release'

А далі — прогін вашого типового workload, особливо якщо там є старі утиліти, Wine, SteamCMD або інші 32-bit залежності.

Антипатерни

• Не зупиняйтеся на Docker upgrade без kernel patch, якщо патч від вендора вже є.
• Не вмикайте seccomp=unconfined для “швидкої стабілізації”.
• Не вважайте, що 29.4.2 і 29.4.3 роблять одне й те саме.
• Не залишайте SELinux mitigation недоконфігурованим і потім не дивуйтеся, що захист поводиться інакше, ніж очікували.
• Не сприймайте це як проблему лише одного контейнера. Спільний хост означає спільний ризик.

Короткий висновок

Правильний порядок дій такий:

1. поставити kernel patch;
2. оновити Docker Engine до 29.4.3+;
3. перевірити, чи правильно працюють AppArmor / SELinux;
4. тільки якщо треба, включати тимчасовий обхід для окремих workloads;
5. не плутати mitigation із повним виправленням.

Copy Fail — хороший приклад того, чому container runtime треба оновлювати не лише заради нових фіч. Іноді це найшвидший спосіб перекрити вузьке, але дуже неприємне вікно ризику, поки ядро ще їде від дистрибутива.

Джерела

• Docker Blog: https://www.docker.com/blog/mitigating-cve-2026-31431-copy-fail-in-docker-engine/
• Docker Docs: https://docs.docker.com/engine/release-notes/29/
• Docker Docs 29.4.3 section: https://docs.docker.com/engine/release-notes/29/#2943