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

exploitDog

fstec логотип

BDU:2026-05869

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

Описание

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

Вендор

Сообщество свободного программного обеспечения
АО «СберТех»

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

Linux
Platform V SberLinux OS Server

Версия ПО

до 6.3 (Linux)
до 9.2.0-fstec (Platform V SberLinux OS Server)
от 4.2 до 5.15.100 (Linux)
от 6.1 до 6.1.18 (Linux)
от 6.2 до 6.2.5 (Linux)

Тип ПО

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

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

Сообщество свободного программного обеспечения Linux до 6.3
АО «СберТех» Platform V SberLinux OS Server до 9.2.0-fstec
Сообщество свободного программного обеспечения Linux от 4.2 до 5.15.100
Сообщество свободного программного обеспечения Linux от 6.1 до 6.1.18
Сообщество свободного программного обеспечения Linux от 6.2 до 6.2.5

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

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

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

В условиях отсутствия обновлений безопасности от производителя рекомендуется придерживаться "Рекомендаций по безопасной настройке операционных систем LINUX", изложенных в методическом документе ФСТЭК России, утверждённом 25 декабря 2022 года.
Использование рекомендаций:
Для Linux:
https://lore.kernel.org/linux-cve-announce/2025091509-CVE-2023-53200-a0c8@gregkh/
https://git.kernel.org/stable/c/0af8c09c896810879387decfba8c942994bb61f5
https://git.kernel.org/stable/c/3cc9610a87b7dde82f7360dd4eb6c2c27940ed57
https://git.kernel.org/stable/c/512b6c4b83c91d007301ea7d7f095d16c3aceacd
https://git.kernel.org/stable/c/e306dbee4c98025a9326386023a12ef4d887e9d1
Для Platform V SberLinux OS Server:
Обновление операционной системы до версии 9.2.0-fstec или выше

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

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

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

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

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

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

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

EPSS

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

5.5 Medium

CVSS3

4.6 Medium

CVSS2

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

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

In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: fix percpu counter block leak on error path when creating new netns Here is the stack where we allocate percpu counter block: +-< __alloc_percpu +-< xt_percpu_counter_alloc +-< find_check_entry # {arp,ip,ip6}_tables.c +-< translate_table And it can be leaked on this code path: +-> ip6t_register_table +-> translate_table # allocates percpu counter block +-> xt_register_table # fails there is no freeing of the counter block on xt_register_table fail. Note: xt_percpu_counter_free should be called to free it like we do in do_replace through cleanup_entry helper (or in __ip6t_unregister_table). Probability of hitting this error path is low AFAICS (xt_register_table can only return ENOMEM here, as it is not replacing anything, as we are creating new netns, and it is hard to imagine that all previous allocations succeeded and after that one in xt_register_table failed). But it's worth fixing even the r...

CVSS3: 4.1
redhat
11 месяцев назад

In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: fix percpu counter block leak on error path when creating new netns Here is the stack where we allocate percpu counter block: +-< __alloc_percpu +-< xt_percpu_counter_alloc +-< find_check_entry # {arp,ip,ip6}_tables.c +-< translate_table And it can be leaked on this code path: +-> ip6t_register_table +-> translate_table # allocates percpu counter block +-> xt_register_table # fails there is no freeing of the counter block on xt_register_table fail. Note: xt_percpu_counter_free should be called to free it like we do in do_replace through cleanup_entry helper (or in __ip6t_unregister_table). Probability of hitting this error path is low AFAICS (xt_register_table can only return ENOMEM here, as it is not replacing anything, as we are creating new netns, and it is hard to imagine that all previous allocations succeeded and after that one in xt_register_table failed). But it's worth fixing even the r...

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

In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: fix percpu counter block leak on error path when creating new netns Here is the stack where we allocate percpu counter block: +-< __alloc_percpu +-< xt_percpu_counter_alloc +-< find_check_entry # {arp,ip,ip6}_tables.c +-< translate_table And it can be leaked on this code path: +-> ip6t_register_table +-> translate_table # allocates percpu counter block +-> xt_register_table # fails there is no freeing of the counter block on xt_register_table fail. Note: xt_percpu_counter_free should be called to free it like we do in do_replace through cleanup_entry helper (or in __ip6t_unregister_table). Probability of hitting this error path is low AFAICS (xt_register_table can only return ENOMEM here, as it is not replacing anything, as we are creating new netns, and it is hard to imagine that all previous allocations succeeded and after that one in xt_register_table failed)

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

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

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

In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: fix percpu counter block leak on error path when creating new netns Here is the stack where we allocate percpu counter block: +-< __alloc_percpu +-< xt_percpu_counter_alloc +-< find_check_entry # {arp,ip,ip6}_tables.c +-< translate_table And it can be leaked on this code path: +-> ip6t_register_table +-> translate_table # allocates percpu counter block +-> xt_register_table # fails there is no freeing of the counter block on xt_register_table fail. Note: xt_percpu_counter_free should be called to free it like we do in do_replace through cleanup_entry helper (or in __ip6t_unregister_table). Probability of hitting this error path is low AFAICS (xt_register_table can only return ENOMEM here, as it is not replacing anything, as we are creating new netns, and it is hard to imagine that all previous allocations succeeded and after that one in xt_register_table fail...

EPSS

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

5.5 Medium

CVSS3

4.6 Medium

CVSS2