В ядре Linux устранена следующая уязвимость:
SUNRPC: отклонить повторяющиеся параметры CREDS_VALUE
gssx_dec_option_array() просматривает массив опций, предоставленный проводом, и, для
каждая запись, имя которой соответствует CREDS_VALUE, вызывает
gssx_dec_linux_creds() в той же структуре svc_cred. Этот помощник
безоговорочно устанавливает новый результат groups_alloc() в
creds->cr_group_info, не отпуская уже существующий указатель
там:
для (я = 0; я <счет; я++) {
... расшифровать имя ...
если (длина == sizeof(CREDS_VALUE) &&
memcmp(p, CREDS_VALUE, sizeof(CREDS_VALUE)) == 0) {
ошибка = gssx_dec_linux_creds (xdr, creds);
...
}
}
Поэтому ответ, содержащий две записи CREDS_VALUE, перезаписывает
cr_group_info на второй итерации и теряет group_info
выделяется при первом вызове. Только более ранний путь free_creds
освобождает последнюю cr_group_info через free_svc_cred(), поэтому первая
счетчик ссылок выделения остается равным единице, а его хранилище, поддерживаемое kvmalloc
утечка.
Нет вызова внутри дерева gssp_accept_sec_context_upcall()
ожидает более одного CREDS_VALUE за ответ. Исправьте, отслеживая, была ли опция CREDS_VALUE уже использована.
декодируется и возвращает -EINVAL при любом последующем совпадении, поэтому
Путь free_creds освобождает единственную установленную группу group_info.
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: SUNRPC: reject duplicate CREDS_VALUE options gssx_dec_option_array() walks the wire-supplied option array and, for every entry whose name matches CREDS_VALUE, calls gssx_dec_linux_creds() on the same struct svc_cred. That helper unconditionally installs a fresh groups_alloc() result into creds->cr_group_info without releasing whatever pointer was already there: for (i = 0; i < count; i++) { ... decode name ... if (length == sizeof(CREDS_VALUE) && memcmp(p, CREDS_VALUE, sizeof(CREDS_VALUE)) == 0) { err = gssx_dec_linux_creds(xdr, creds); ... } } A reply that carries two CREDS_VALUE entries therefore overwrites cr_group_info on the second iteration and orphans the group_info allocated by the first call. The earlier free_creds path only releases the last cr_group_info via free_svc_cred(), so the first allocation's refcount stays at one and its kvmalloc-backed storage is leaked. No in-tree caller of gssp_accept_sec_context_upcall() expects more than one CREDS_VALUE per reply. Fix by tracking whether a CREDS_VALUE option has already been decoded and returning -EINVAL on any subsequent match, so the free_creds path releases the single group_info that was installed.