GhostLock у ядрі Linux: кому загрожує вразливість і що перевірити

У ядрі Linux розкрили вразливість GhostLock, яка дозволяє перетворити вже наявний непривілейований доступ на права root. Це серйозна помилка, але не готовий спосіб віддалено зламати сервер: спочатку нападник має отримати можливість виконувати код на самій системі або всередині контейнера.

Що саме оприлюднили

7 липня Nebula Security опублікувала технічний розбір GhostLock, зареєстрованої як CVE-2026-43499. Помилка міститься в механізмі real-time mutex ядра Linux і з’явилася ще у версії 2.6.39, випущеній у 2011 році. Виправлення потрапило до проєкту ядра у квітні 2026 року, після чого його почали переносити до підтримуваних стабільних гілок.

CNA проєкту kernel.org оцінила вразливість у 7,8 бала за CVSS 3.1 — це високий рівень. NVD показує цю оцінку, однак на момент підготовки матеріалу ще не надала власної. Вектор атаки тут важливіший за саму цифру: йдеться про локальне підвищення привілеїв, а не про вразливий мережевий порт, до якого можна напряму під’єднатися з інтернету.

Спочатку потрібне виконання коду

Щоб скористатися GhostLock, зловмисник уже повинен мати непривілейований обліковий запис або інший локальний плацдарм. Ним може бути зламана програма, окрема вразливість із можливістю запускати команди, доступ розробника до спільного сервера чи код, запущений у контейнері. Сама CVE-2026-43499 такого початкового доступу не створює.

Наслідок успішної атаки значно небезпечніший: процес може перейти від звичайного користувача до контролю на рівні ядра. Дослідники Nebula також заявляють, що їхній експлойт виходить із контейнера та отримує root на хостовій системі. Тому насамперед варто оновлювати CI-сервери, платформи контейнеризації, спільні машини розробників і багатокористувацькі хости, де запуск чужого або напівдовіреного коду є частиною щоденної роботи.

Як виникає помилка в ядрі

Проблема з’являється під час очищення стану в операціях futex із успадкуванням пріоритетів. Функція remove_waiter() прибирає завдання, яке очікує на блокування. У звичайному сценарії поточне завдання і власник структури очікування збігаються. Проте під час відкочування proxy-lock це можуть бути різні завдання.

Старий код працював зі структурою поточного процесу замість фактичного процесу-очікувача. Через це поле pi_blocked_on могло зберегти посилання на об’єкт у стеку ядра вже після завершення його життєвого циклу. Так виникає use-after-free — звернення до пам’яті, яка більше не належить попередньому об’єкту. Патч переводить очищення на waiter->task, бере блокування потрібного завдання і видаляє правильний покажчик.

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

Звідки взялися 97% і п’ять секунд

Nebula повідомляє про 97-відсоткову надійність свого експлойта та результат близько п’яти секунд у середовищі kernelCTF. За цю роботу Google виплатила дослідникам $92 337. Це дані авторів експлойта для конкретних тестових цілей, а не незалежний замір для всіх процесорів, конфігурацій і дистрибутивів. NVD не підтверджує ані швидкість, ані заявлений відсоток успіху.

Окремий практичний сигнал надійшов зі списку розсилки oss-security. Томас Оргіс повідомив, що опублікований proof of concept спричинив зависання або аварійне завершення Ubuntu з ядром 7.0.0-14. Водночас Debian 13 із 6.12.95 та звичайне ядро 6.6.144 у його перевірці не виявилися вразливими — ймовірно, у цих збірках уже був backport виправлення. Це корисне спостереження, але не повний тест усіх систем.

Чому одного номера версії недостатньо

У даних NVD як виправлені межі стабільних гілок зазначені, зокрема, 6.1.175, 6.6.140, 6.12.86, 6.18.27, 7.0.4 та 7.1. Водночас різні результати для пакетів Ubuntu й Debian у повідомленні oss-security показують, чому орієнтуватися лише на номер небезпечно: в одному пакеті виправлення вже може бути перенесене до старішої гілки, тоді як інша новіша на вигляд збірка ще потребує уваги.

Тому команда uname -r дає лише частину відповіді. Потрібно знайти бюлетень безпеки або журнал змін саме свого пакета і перевірити згадку CVE-2026-43499 чи відповідного kernel-патча. Після встановлення оновлення варто ще раз перевірити запущене ядро: пакет може бути вже на диску, а сервер — досі працювати зі старою версією до перезавантаження.

Що робити адміністраторам

• Скласти перелік Linux-систем і зафіксувати не лише версію запущеного ядра, а й повну ревізію пакета дистрибутива.
• Перевірити CVE-2026-43499 у бюлетені виробника або changelog пакета, не покладаючись тільки на перші цифри версії.
• Встановити виправлене ядро, виконати потрібне перезавантаження та переконатися, що система завантажила саме нову збірку.
• Першими оновити контейнерні вузли, CI runners, спільні сервери розробки, навчальні й дослідницькі машини та хости з віддаленим доступом.
• Якщо патч доводиться відкласти, тимчасово обмежити можливість запуску коду та рознести чутливі сервіси. Це зменшення ризику, а не усунення вразливості.

У наведених джерелах немає повідомлень про підтверджені атаки GhostLock у реальному середовищі. Водночас у повідомленні oss-security не описано рівноцінного обхідного налаштування чи модуля, який можна просто вимкнути: рекомендований шлях — оновлення ядра. Наявність публічного технічного аналізу й коду для перевірки підвищує терміновість, але сама по собі не доводить масової експлуатації.

Найточніше GhostLock описує поняття «підсилювач уже наявного зламу». Вразливість не відкриває сервер з інтернету, проте здатна зробити невеликий локальний доступ значно небезпечнішим. Правильна відповідь — перевірити backport у свого постачальника, встановити виправлений пакет і впевнитися, що саме це ядро зараз працює.