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

exploitDog

fstec логотип

BDU:2025-06240

Опубликовано: 13 янв. 2023
Источник: fstec
CVSS3: 7.8
CVSS2: 4.6
EPSS Низкий

Описание

Уязвимость функций fscache_is_acquire_pending() и fscache_wake_pending_volume() ядра операционной системы Linux связана с использованием памяти после ее освобождения. Эксплуатация уязвимости может позволить нарушителю вызвать отказ в обслуживании

Вендор

ООО «Ред Софт»
Red Hat Inc.
Сообщество свободного программного обеспечения
Novell Inc.

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

РЕД ОС
Red Hat Enterprise Linux
Linux
SUSE Linux Enterprise Server for SAP Applications
SUSE Linux Enterprise Live Patching
SUSE Linux Enterprise Micro
Suse Linux Enterprise Server
SUSE Linux Enterprise High Performance Computing

Версия ПО

7.3 (РЕД ОС)
9 (Red Hat Enterprise Linux)
до 6.2 (Linux)
15 SP5 (SUSE Linux Enterprise Server for SAP Applications)
15 SP5 (SUSE Linux Enterprise Live Patching)
5.5 (SUSE Linux Enterprise Micro)
15 SP5-LTSS (Suse Linux Enterprise Server)
15 SP5-LTSS (SUSE Linux Enterprise High Performance Computing)
15 SP5-ESPOS (SUSE Linux Enterprise High Performance Computing)
от 6.1.0 до 6.1.11 (Linux)

Тип ПО

Операционная система
Прикладное ПО информационных систем

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

ООО «Ред Софт» РЕД ОС 7.3
Red Hat Inc. Red Hat Enterprise Linux 9
Сообщество свободного программного обеспечения Linux до 6.2
Novell Inc. SUSE Linux Enterprise Server for SAP Applications 15 SP5
Novell Inc. Suse Linux Enterprise Server 15 SP5-LTSS
Сообщество свободного программного обеспечения Linux от 6.1.0 до 6.1.11

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

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

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

В условиях отсутствия обновлений безопасности от производителя рекомендуется придерживаться "Рекомендаций по безопасной настройке операционных систем LINUX", изложенных в методическом документе ФСТЭК России, утверждённом 25 декабря 2022 года.
Использование рекомендаций:
Для Linux:
https://git.kernel.org/stable/c/3be069f42a7b79d3149194f21cdf24bf23864cac
https://git.kernel.org/stable/c/8226e37d82f43657da34dd770e2b38f20242ada7
Для РедОС:
http://repo.red-soft.ru/redos/7.3c/x86_64/updates/
Для программных продуктов Red Hat Inc.:
https://access.redhat.com/security/cve/CVE-2023-52982
Для программных продуктов Novell Inc.:
https://www.suse.com/security/cve/CVE-2023-52982.html

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

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

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

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

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

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

EPSS

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

7.8 High

CVSS3

4.6 Medium

CVSS2

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

ubuntu
3 месяца назад

In the Linux kernel, the following vulnerability has been resolved: fscache: Use wait_on_bit() to wait for the freeing of relinquished volume The freeing of relinquished volume will wake up the pending volume acquisition by using wake_up_bit(), however it is mismatched with wait_var_event() used in fscache_wait_on_volume_collision() and it will never wake up the waiter in the wait-queue because these two functions operate on different wait-queues. According to the implementation in fscache_wait_on_volume_collision(), if the wake-up of pending acquisition is delayed longer than 20 seconds (e.g., due to the delay of on-demand fd closing), the first wait_var_event_timeout() will timeout and the following wait_var_event() will hang forever as shown below: FS-Cache: Potential volume collision new=00000024 old=00000022 ...... INFO: task mount:1148 blocked for more than 122 seconds. Not tainted 6.1.0-rc6+ #1 task:mount state:D stack:0 pid:1148 ppid:1 Call Trace: <TASK> _...

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

In the Linux kernel, the following vulnerability has been resolved: fscache: Use wait_on_bit() to wait for the freeing of relinquished volume The freeing of relinquished volume will wake up the pending volume acquisition by using wake_up_bit(), however it is mismatched with wait_var_event() used in fscache_wait_on_volume_collision() and it will never wake up the waiter in the wait-queue because these two functions operate on different wait-queues. According to the implementation in fscache_wait_on_volume_collision(), if the wake-up of pending acquisition is delayed longer than 20 seconds (e.g., due to the delay of on-demand fd closing), the first wait_var_event_timeout() will timeout and the following wait_var_event() will hang forever as shown below: FS-Cache: Potential volume collision new=00000024 old=00000022 ...... INFO: task mount:1148 blocked for more than 122 seconds. Not tainted 6.1.0-rc6+ #1 task:mount state:D stack:0 pid:1148 ppid:1 Call Trace: <TASK> __sch...

nvd
3 месяца назад

In the Linux kernel, the following vulnerability has been resolved: fscache: Use wait_on_bit() to wait for the freeing of relinquished volume The freeing of relinquished volume will wake up the pending volume acquisition by using wake_up_bit(), however it is mismatched with wait_var_event() used in fscache_wait_on_volume_collision() and it will never wake up the waiter in the wait-queue because these two functions operate on different wait-queues. According to the implementation in fscache_wait_on_volume_collision(), if the wake-up of pending acquisition is delayed longer than 20 seconds (e.g., due to the delay of on-demand fd closing), the first wait_var_event_timeout() will timeout and the following wait_var_event() will hang forever as shown below: FS-Cache: Potential volume collision new=00000024 old=00000022 ...... INFO: task mount:1148 blocked for more than 122 seconds. Not tainted 6.1.0-rc6+ #1 task:mount state:D stack:0 pid:1148 ppid:1 Call Trace:

debian
3 месяца назад

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

github
3 месяца назад

In the Linux kernel, the following vulnerability has been resolved: fscache: Use wait_on_bit() to wait for the freeing of relinquished volume The freeing of relinquished volume will wake up the pending volume acquisition by using wake_up_bit(), however it is mismatched with wait_var_event() used in fscache_wait_on_volume_collision() and it will never wake up the waiter in the wait-queue because these two functions operate on different wait-queues. According to the implementation in fscache_wait_on_volume_collision(), if the wake-up of pending acquisition is delayed longer than 20 seconds (e.g., due to the delay of on-demand fd closing), the first wait_var_event_timeout() will timeout and the following wait_var_event() will hang forever as shown below: FS-Cache: Potential volume collision new=00000024 old=00000022 ...... INFO: task mount:1148 blocked for more than 122 seconds. Not tainted 6.1.0-rc6+ #1 task:mount state:D stack:0 pid:1148 ppid:1 Call Tra...

EPSS

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

7.8 High

CVSS3

4.6 Medium

CVSS2