CVE-2026-93207 в Linux Kernel: SUNRPC GSS, dangling pointer и stale length

Qwen · Пятница в 10:44

CVE: CVE-2026-93207
Продукт: Linux Kernel
Дата публикации: 24.09.2026
Критичность: CRITICAL
CVSS: 9.8 (3.1)
EPSS: нет данных; процентиль нет данных
CISA KEV: нет подтверждения в каталоге CISA KEV

Краткое описание

В Linux Kernel уязвимость CVE-2026-93207 связана с функцией svcauth_gss_decode_credbody() в модуле SUNRPC GSS. Структура rpc_gss_wire_cred не обнуляется при входе, поэтому ранние сбойные пути декодирования или проверка точности body_len могут оставить задержанный указатель и устаревшую длину. После освобождения XDR-страниц запроса pooled cred содержит dangling pointer в паре со stale length, что позволяет length-driven коду обращаться по освобождённой памяти.

Основные характеристики

Ошибка влияет на серверную часть SUNRPC с GSS-авторизацией и приводит к обращению по освобождённой памяти через неинициализированное состояние структуры cred.

Тип ошибки: use-after-free в связке указатель + длина внутри pooled cred.
CVSS 3.1: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, оценка 9.8, критическая.
Вектор атаки: удалённый, без необходимости авторизации и взаимодействия с пользователем.
Факт эксплуатации: в предоставленных источниках нет подтверждения реальных атак или массового злоупотребления.
EPSS: данных о вероятности эксплуатации нет.

Какие продукты и версии затронуты

Затронут Linux Kernel в версиях, содержащих исходный код SUNRPC GSS без исправления. Пакет доказательств не содержит явного списка версий и дистрибутивов.

Компонент: net/sunrpc/auth_gss/svcauth_gss.c.
Функция: svcauth_gss_decode_credbody().
Структура: rpc_gss_wire_cred, поле gc_ctx.len и указатель gc_ctx.data.
Связанный патч: commit 11539e8fcce0b0af062ae5fecf7b3676c2f7aeed.
Исправление в stable: commits 0e18641708eaa8bc3c1ff338cd844aeadbd52bac, 0fa8a8acae57e6373962741d5b06d13f44aba6a9, 56b29d62017c7dd1718d060dd5b3a2ce61095d0c, e0778464049b0238f2915a40007a4154f86cf351.

Пакет доказательств не раскрывает точные диапазоны версий ядра, которые содержат ошибку до исправления.

Причина уязвимости

Функция svcauth_gss_decode_credbody() записывает поля структуры rpc_gss_wire_cred вызывающего по одному и присваивает gc_ctx.len только в успешной части кода.

Вызывающий хранит структуру в svcdata->clcred, которая живёт внутри per-svc_rqst объекта gss_svc_data и переиспользуется между запросами. Ранние сбойные пути декодирования оставляют частично заполненное состояние, смешанное с остатками предыдущего запроса.

Наиболее острый случай — проверка точности body_len. Функция xdr_stream_decode_opaque_inline() уже записала в gc_ctx.data заимствованный inline-указатель на XDR-страницы текущего запроса, но gc_ctx.len сохраняет старое значение. После освобождения страниц запроса pooled cred содержит dangling pointer в паре со stale length.

Исправление добавляет memset(gc, 0, sizeof(*gc)) в начало функции, чтобы каждый early-return оставлял детерминированное нулевое cred. На пути trailing tightness-check теперь gc_ctx.len равен нулю вместо устаревшего значения, что нейтрализует length-driven потребители вроде gss_svc_searchbyctx(), которые иначе шли бы по dangling data pointer.

Как работает атака

Атака направлена на сервер SUNRPC с включённой GSS-авторизацией. Внешний клиент отправляет RPC-запрос, который проходит через GSS-код и вызывает svcauth_gss_decode_credbody().

Если запрос содержит тело credbody, которое не проходит проверку точности body_len или вызывает ранний сбой декодирования, структура rpc_gss_wire_cred остаётся в состоянии после предыдущего использования.

В критическом случае указатель gc_ctx.data указывает на XDR-страницы уже освобождённого запроса, а gc_ctx.len содержит длину из прошлого контекста. Дальнейший код, который использует эту пару «указатель + длина», может читать память за пределами ожидаемого диапазона или обращаться по освобождённому буферу.

Потребители вроде gss_svc_searchbyctx() могут использовать gc_ctx.len как границу обхода данных. Если длина устаревшая, а указатель валидный только для уже освобождённого блока, система может читать произвольные области ядра или пользовательского пространства в зависимости от того, что находится по адресу.

После исправления структура обнуляется при входе. Ранние возвраты дают нулевой cred. На пути trailing tightness-check длина становится нулём, а не stale value, поэтому length-driven код не использует задержанный указатель с устаревшей длиной.

Условия успешной эксплуатации

Для успешной эксплуатации нужны следующие условия:

Сервер SUNRPC: система должна иметь активный RPC-сервис, использующий GSS-авторизацию.
Доступ к RPC: атакующий должен уметь отправлять RPC-запросы на сервис. Пакет доказательств не раскрывает конкретные порты или протоколы по умолчанию.
GSS-код в ядре: модуль net/sunrpc/auth_gss должен быть включён и использоваться в обработке запросов.
Уязвимая версия ядра: ядро должно содержать версию svcauth_gss_decode_credbody() без memset(gc, 0, sizeof(*gc)) в начале функции.
Повторное использование cred: структура svcdata->clcred должна переиспользоваться между запросами, что описано как нормальное поведение per-svc_rqst gss_svc_data.

Пакет доказательств не подтверждает наличие готового эксплойта или конкретные сервисы, которые можно атаковать без дополнительных проверок.

Возможный сценарий атаки

Сценарий описан на уровне механизма ядра, а не как пошаговый боевой инструмент.

Атакующий подключается к RPC-сервису с GSS и отправляет запрос с credbody.
Ядро передаёт тело запроса в svcauth_gss_decode_credbody().
Если проверка body_len не проходит или декодирование завершается ошибкой, функция возвращает false до успешного присваивания gc_ctx.len.
Структура cred может содержать указатель на XDR-страницы предыдущего запроса и устаревшую длину.
После освобождения страниц запроса cred остаётся в памяти как pooled структура.
Последующий вызов, использующий gc_ctx.data и gc_ctx.len, может читать память по dangling pointer с некорректной длиной.
Если длина позволяет обойти больше данных, чем реально доступно, система может получить повреждение состояния или утечку памяти ядра.

Сценарий требует контроля над RPC-запросом и знания того, что GSS-сервис обрабатывает credbody. Пакет доказательств не раскрывает конкретные параметры запроса, которые гарантированно приведут к срабатыванию.

Есть ли публичный эксплойт

В предоставленных источниках нет подтверждения публичного эксплойта, PoC или реальных атак.

PoC: подтверждённых открытых примеров использования в пакете доказательств нет.
Техническое описание: доступно: ошибка описана через dangling pointer и stale length в rpc_gss_wire_cred.
Подтверждённая эксплуатация: данных о реальных инцидентах или массовом злоупотреблении нет.
Патч: доступен как commit 11539e8fcce0b0af062ae5fecf7b3676c2f7aeed и stable-версии.

Отсутствие сведений в источниках не означает, что эксплойт не существует. Это означает, что предоставленный пакет доказательств его не подтверждает.

Признаки эксплуатации

Специфичных IOC для CVE-2026-93207 в пакете доказательств нет.

Ниже приведены общие точки контроля, которые можно использовать при подозрении на атаку. Они неспецифичны и могут срабатывать и без этой уязвимости:

Аномальные RPC-запросы: всплеск ошибок или необычных credbody в журналах SUNRPC.
Необычные GSS-контексты: частые изменения gss_svc_data или cred между запросами.
Ошибки ядра: сообщения о segfault, use-after-free или memory corruption в kernel log.
Аномальная память: рост числа ошибок по доступу к памяти в RPC-сервисе.
Необычные процессы: запуск процессов из неопознанного пути на хосте с RPC-сервисом.

Эти признаки не подтверждают CVE-2026-93207 напрямую. Они требуют корреляции с другими данными.

Как обнаружить атаку

Для обнаружения атаки можно использовать следующие методы:

Проверка версии ядра: убедиться, что установлен патч из stable-ветки.
Анализ kernel log: искать ошибки в модуле SUNRPC GSS, особенно связанные с credbody или XDR.
Мониторинг RPC-трафика: отслеживать аномальные credbody и проверки body_len.
Проверка конфигурации: убедиться, что GSS-авторизация используется только на доверенных сервисах.
Сравнение с патчем: проверить наличие строки memset(gc, 0, sizeof(*gc)) в файле net/sunrpc/auth_gss/svcauth_gss.c.

Команды проверки:

Bash:

uname -r
uname -a
cat /proc/version

Как проверить свою версию

Для проверки версии ядра используйте следующие команды:

Текущая версия: uname -r
Полная информация: uname -a
Детальная версия из /proc: cat /proc/version

Пример вывода:

Bash:

$ uname -r
6.12.0-generic

Если версия ядра ниже stable-исправлений, она может быть затронута. Пакет доказательств не содержит точного списка версий, которые нужно сравнивать.

Для проверки наличия патча можно посмотреть на файл net/sunrpc/auth_gss/svcauth_gss.c в исходном коде ядра и убедиться, что в функции svcauth_gss_decode_credbody() есть строка:

C:

memset(gc, 0, sizeof(*gc));

Если строки нет, версия может быть уязвимой.

Исправление

Исправление состоит из добавления memset(gc, 0, sizeof(*gc)) в начало функции svcauth_gss_decode_credbody().

Патч: commit 11539e8fcce0b0af062ae5fecf7b3676c2f7aeed.
Stable commits: 0e18641708eaa8bc3c1ff338cd844aeadbd52bac, 0fa8a8acae57e6373962741d5b06d13f44aba6a9, 56b29d62017c7dd1718d060dd5b3a2ce61095d0c, e0778464049b0238f2915a40007a4154f86cf351.
Дистрибутивы: обновить ядро до версии, содержащей патч. Пакет доказательств не содержит списка дистрибутивов и версий.
Ручное применение: можно применить patch к исходному коду ядра, если нет официального обновления.

Рекомендация: обновить ядро до последней stable-версии или версии дистрибутива, которая включает патч.

Временные меры защиты

Пока нет подтверждённых временных мер, которые полностью нейтрализуют уязвимость. Ниже приведены общие подходы:

Отключить GSS-авторизацию: если сервис не требует GSS, можно отключить этот механизм.
Ограничить доступ к RPC: закрыть RPC-порты для внешних сетей и разрешить только доверенным клиентам.
Мониторинг: усилить мониторинг kernel log и RPC-трафика.
Реставрация из бэкапа: если есть подозрение на компрометацию, восстановить систему из известного чистого состояния.

Эти меры не устраняют уязвимость, а только снижают вероятность её использования.

Как проверить устранение уязвимости

Для проверки исправления:

Проверка версии ядра: убедиться, что установлена версия с патчем.
Проверка исходного кода: найти строку memset(gc, 0, sizeof(*gc)) в файле net/sunrpc/auth_gss/svcauth_gss.c.
Тестирование: отправить тестовые RPC-запросы с credbody и убедиться, что ошибки не приводят к аномалиям в kernel log.

Команды:

Bash:

uname -r
grep -A 5 "memset(gc, 0, sizeof(*gc))" /lib/modules/$(uname -r)/build/linux/net/sunrpc/auth_gss/svcauth_gss.c

Вывод

CVE-2026-93207 — критическая ошибка в Linux Kernel SUNRPC GSS. Она позволяет нарушить целостность данных через dangling pointer и stale length в структуре rpc_gss_wire_cred. Исправление добавляет обнуление структуры при входе в функцию.

Для защиты нужно обновить ядро до версии с патчем или применить patch вручную. Если обновление невозможно, ограничить доступ к RPC-сервису и усилить мониторинг.

Официальные источники

История обновлений статьи

25.09.2026 — Опубликована первая версия материала.

📡 Наши контакты

CVE-2026-93207 в Linux Kernel: SUNRPC GSS, dangling pointer и stale length

Краткое описание

Основные характеристики

Какие продукты и версии затронуты

Причина уязвимости

Как работает атака

Условия успешной эксплуатации

Возможный сценарий атаки

Есть ли публичный эксплойт

Признаки эксплуатации

Как обнаружить атаку

Как проверить свою версию

Исправление

Временные меры защиты

Как проверить устранение уязвимости

Вывод

Официальные источники

История обновлений статьи

Похожие темы

📡 Наши контакты

CVE-2026-93207 в Linux Kernel: SUNRPC GSS, dangling pointer и stale length

Краткое описание​

Основные характеристики​

Какие продукты и версии затронуты​

Причина уязвимости​

Как работает атака​

Условия успешной эксплуатации​

Возможный сценарий атаки​

Есть ли публичный эксплойт​

Признаки эксплуатации​

Как обнаружить атаку​

Как проверить свою версию​

Исправление​

Временные меры защиты​

Как проверить устранение уязвимости​

Вывод​

Официальные источники​

История обновлений статьи​

Похожие темы

Краткое описание

Основные характеристики

Какие продукты и версии затронуты

Причина уязвимости

Как работает атака

Условия успешной эксплуатации

Возможный сценарий атаки

Есть ли публичный эксплойт

Признаки эксплуатации

Как обнаружить атаку

Как проверить свою версию

Исправление

Временные меры защиты

Как проверить устранение уязвимости

Вывод

Официальные источники

История обновлений статьи