Логотип exploitDog
Консоль
Логотип exploitDog

exploitDog

fstec логотип

BDU:2026-05764

Опубликовано: 23 фев. 2026
Источник: fstec
CVSS3: 5.5
CVSS2: 4.6
EPSS Низкий

Описание

Уязвимость компонента sunrpc ядра операционной системы Linux связана с неосвобождением ресурса после истечения действительного срока его эксплуатирования. Эксплуатация уязвимости может позволить нарушителю вызвать отказ в обслуживании

Вендор

Red Hat Inc.
Canonical Ltd.
АО «ИВК»
Сообщество свободного программного обеспечения

Наименование ПО

Red Hat Enterprise Linux
Ubuntu
Альт 8 СП
АЛЬТ СП 10
Linux

Версия ПО

7 (Red Hat Enterprise Linux)
16.04 LTS (Ubuntu)
18.04 LTS (Ubuntu)
8 (Red Hat Enterprise Linux)
20.04 LTS (Ubuntu)
- (Альт 8 СП)
22.04 LTS (Ubuntu)
9 (Red Hat Enterprise Linux)
- (АЛЬТ СП 10)
24.04 LTS (Ubuntu)
10 (Red Hat Enterprise Linux)
до 7.0 rc5 (Linux)
от 6.18 до 6.18.20 (Linux)
от 6.19 до 6.19.10 (Linux)
от 6.1 до 6.1.167 (Linux)
от 6.6 до 6.6.130 (Linux)
от 6.12 до 6.12.78 (Linux)

Тип ПО

Операционная система

Операционные системы и аппаратные платформы

Red Hat Inc. Red Hat Enterprise Linux 7
Canonical Ltd. Ubuntu 16.04 LTS
Canonical Ltd. Ubuntu 18.04 LTS
Red Hat Inc. Red Hat Enterprise Linux 8
Canonical Ltd. Ubuntu 20.04 LTS
АО «ИВК» Альт 8 СП -
Canonical Ltd. Ubuntu 22.04 LTS
Red Hat Inc. Red Hat Enterprise Linux 9
АО «ИВК» АЛЬТ СП 10 -
Canonical Ltd. Ubuntu 24.04 LTS
Red Hat Inc. Red Hat Enterprise Linux 10
Сообщество свободного программного обеспечения Linux до 7.0 rc5
Сообщество свободного программного обеспечения Linux от 6.18 до 6.18.20
Сообщество свободного программного обеспечения Linux от 6.19 до 6.19.10
Сообщество свободного программного обеспечения Linux от 6.1 до 6.1.167
Сообщество свободного программного обеспечения Linux от 6.6 до 6.6.130
Сообщество свободного программного обеспечения Linux от 6.12 до 6.12.78

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

Средний уровень опасности (базовая оценка CVSS 2.0 составляет 4,6)
Средний уровень опасности (базовая оценка CVSS 3.1 составляет 5,5)

Возможные меры по устранению уязвимости

В условиях отсутствия обновлений безопасности от производителя рекомендуется придерживаться "Рекомендаций по безопасной настройке операционных систем LINUX", изложенных в методическом документе ФСТЭК России, утверждённом 25 декабря 2022 года.
Использование рекомендаций:
Для Linux:
https://lore.kernel.org/linux-cve-announce/2026040327-CVE-2026-31400-db79@gregkh/
Для программных продуктов Red Hat Inc.:
https://access.redhat.com/security/cve/cve-2026-31400
Для Ubuntu:
https://ubuntu.com/security/CVE-2026-31400
Для ОС АЛЬТ СП 10: установка обновления из публичного репозитория программного средства: https://altsp.su/obnovleniya-bezopasnosti/
Для ОС Альт 8 СП: установка обновления из публичного репозитория программного средства: https://altsp.su/obnovleniya-bezopasnosti/

Статус уязвимости

Подтверждена производителем

Наличие эксплойта

Данные уточняются

Информация об устранении

Уязвимость устранена

Идентификаторы других систем описаний уязвимостей

EPSS

Процентиль: 2%
0.00117
Низкий

5.5 Medium

CVSS3

4.6 Medium

CVSS2

Связанные уязвимости

CVSS3: 5.5
ubuntu
4 месяца назад

In the Linux kernel, the following vulnerability has been resolved: sunrpc: fix cache_request leak in cache_release When a reader's file descriptor is closed while in the middle of reading a cache_request (rp->offset != 0), cache_release() decrements the request's readers count but never checks whether it should free the request. In cache_read(), when readers drops to 0 and CACHE_PENDING is clear, the cache_request is removed from the queue and freed along with its buffer and cache_head reference. cache_release() lacks this cleanup. The only other path that frees requests with readers == 0 is cache_dequeue(), but it runs only when CACHE_PENDING transitions from set to clear. If that transition already happened while readers was still non-zero, cache_dequeue() will have skipped the request, and no subsequent call will clean it up. Add the same cleanup logic from cache_read() to cache_release(): after decrementing readers, check if it reached 0 with CACHE_PENDING clear, and if so, deq...

CVSS3: 5.5
redhat
4 месяца назад

In the Linux kernel, the following vulnerability has been resolved: sunrpc: fix cache_request leak in cache_release When a reader's file descriptor is closed while in the middle of reading a cache_request (rp->offset != 0), cache_release() decrements the request's readers count but never checks whether it should free the request. In cache_read(), when readers drops to 0 and CACHE_PENDING is clear, the cache_request is removed from the queue and freed along with its buffer and cache_head reference. cache_release() lacks this cleanup. The only other path that frees requests with readers == 0 is cache_dequeue(), but it runs only when CACHE_PENDING transitions from set to clear. If that transition already happened while readers was still non-zero, cache_dequeue() will have skipped the request, and no subsequent call will clean it up. Add the same cleanup logic from cache_read() to cache_release(): after decrementing readers, check if it reached 0 with CACHE_PENDING clear, and if so, deq...

CVSS3: 5.5
nvd
4 месяца назад

In the Linux kernel, the following vulnerability has been resolved: sunrpc: fix cache_request leak in cache_release When a reader's file descriptor is closed while in the middle of reading a cache_request (rp->offset != 0), cache_release() decrements the request's readers count but never checks whether it should free the request. In cache_read(), when readers drops to 0 and CACHE_PENDING is clear, the cache_request is removed from the queue and freed along with its buffer and cache_head reference. cache_release() lacks this cleanup. The only other path that frees requests with readers == 0 is cache_dequeue(), but it runs only when CACHE_PENDING transitions from set to clear. If that transition already happened while readers was still non-zero, cache_dequeue() will have skipped the request, and no subsequent call will clean it up. Add the same cleanup logic from cache_read() to cache_release(): after decrementing readers, check if it reached 0 with CACHE_PENDING clear, and if so, d

CVSS3: 5.5
debian
4 месяца назад

In the Linux kernel, the following vulnerability has been resolved: s ...

CVSS3: 5.5
github
4 месяца назад

In the Linux kernel, the following vulnerability has been resolved: sunrpc: fix cache_request leak in cache_release When a reader's file descriptor is closed while in the middle of reading a cache_request (rp->offset != 0), cache_release() decrements the request's readers count but never checks whether it should free the request. In cache_read(), when readers drops to 0 and CACHE_PENDING is clear, the cache_request is removed from the queue and freed along with its buffer and cache_head reference. cache_release() lacks this cleanup. The only other path that frees requests with readers == 0 is cache_dequeue(), but it runs only when CACHE_PENDING transitions from set to clear. If that transition already happened while readers was still non-zero, cache_dequeue() will have skipped the request, and no subsequent call will clean it up. Add the same cleanup logic from cache_read() to cache_release(): after decrementing readers, check if it reached 0 with CACHE_PENDING clear, and if so...

EPSS

Процентиль: 2%
0.00117
Низкий

5.5 Medium

CVSS3

4.6 Medium

CVSS2