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

exploitDog

fstec логотип

BDU:2025-09816

Опубликовано: 07 июл. 2025
Источник: fstec
CVSS3: 7.3
CVSS2: 7.1
EPSS Низкий

Описание

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

Вендор

Red Hat Inc.
Сообщество свободного программного обеспечения

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

Red Hat Enterprise Linux
Linux
Debian GNU/Linux

Версия ПО

10 (Red Hat Enterprise Linux)
до 6.16 rc6 (Linux)
от 6.15.0 до 6.15.7 (Linux)
от 6.12.0 до 6.12.39 (Linux)
13 (Debian GNU/Linux)
от 6.5 до 6.6.99 (Linux)

Тип ПО

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

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

Red Hat Inc. Red Hat Enterprise Linux 10
Сообщество свободного программного обеспечения Linux до 6.16 rc6
Сообщество свободного программного обеспечения Linux от 6.15.0 до 6.15.7
Сообщество свободного программного обеспечения Linux от 6.12.0 до 6.12.39
Сообщество свободного программного обеспечения Linux от 6.6.0 до 6.6.99
Сообщество свободного программного обеспечения Debian GNU/Linux 13
Сообщество свободного программного обеспечения Linux от 6.5 до 6.6.99

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

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

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

В условиях отсутствия обновлений безопасности от производителя рекомендуется придерживаться "Рекомендаций по безопасной настройке операционных систем LINUX", изложенных в методическом документе ФСТЭК России, утверждённом 25 декабря 2022 года.
Использование рекомендаций:
Для Linux:
https://lore.kernel.org/linux-cve-announce/2025072508-CVE-2025-38463-f4a1@gregkh/
https://git.kernel.org/stable/c/62e6160cfb5514787bda833d466509edc38fde23
https://git.kernel.org/stable/c/81373cd1d72d87c7d844d4454a526b8f53e72d00
https://git.kernel.org/stable/c/9f164fa6bb09fbcc60fa5c3ff551ce9eec1befd7
https://git.kernel.org/stable/c/d3a5f2871adc0c61c61869f37f3e697d97f03d8c
Для Debian GNU/Linux:
https://security-tracker.debian.org/tracker/CVE-2025-38463
Для продуктов Red Hat Inc.:
https://access.redhat.com/security/cve/CVE-2025-38463

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

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

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

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

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

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

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

EPSS

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

7.3 High

CVSS3

7.1 High

CVSS2

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

ubuntu
около 1 месяца назад

In the Linux kernel, the following vulnerability has been resolved: tcp: Correct signedness in skb remaining space calculation Syzkaller reported a bug [1] where sk->sk_forward_alloc can overflow. When we send data, if an skb exists at the tail of the write queue, the kernel will attempt to append the new data to that skb. However, the code that checks for available space in the skb is flawed: ''' copy = size_goal - skb->len ''' The types of the variables involved are: ''' copy: ssize_t (s64 on 64-bit systems) size_goal: int skb->len: unsigned int ''' Due to C's type promotion rules, the signed size_goal is converted to an unsigned int to match skb->len before the subtraction. The result is an unsigned int. When this unsigned int result is then assigned to the s64 copy variable, it is zero-extended, preserving its non-negative value. Consequently, copy is always >= 0. Assume we are sending 2GB of data and size_goal has been adjusted to a value smaller than skb->len. The subtraction ...

CVSS3: 7.3
redhat
около 1 месяца назад

In the Linux kernel, the following vulnerability has been resolved: tcp: Correct signedness in skb remaining space calculation Syzkaller reported a bug [1] where sk->sk_forward_alloc can overflow. When we send data, if an skb exists at the tail of the write queue, the kernel will attempt to append the new data to that skb. However, the code that checks for available space in the skb is flawed: ''' copy = size_goal - skb->len ''' The types of the variables involved are: ''' copy: ssize_t (s64 on 64-bit systems) size_goal: int skb->len: unsigned int ''' Due to C's type promotion rules, the signed size_goal is converted to an unsigned int to match skb->len before the subtraction. The result is an unsigned int. When this unsigned int result is then assigned to the s64 copy variable, it is zero-extended, preserving its non-negative value. Consequently, copy is always >= 0. Assume we are sending 2GB of data and size_goal has been adjusted to a value smaller than skb->len. The subtraction ...

nvd
около 1 месяца назад

In the Linux kernel, the following vulnerability has been resolved: tcp: Correct signedness in skb remaining space calculation Syzkaller reported a bug [1] where sk->sk_forward_alloc can overflow. When we send data, if an skb exists at the tail of the write queue, the kernel will attempt to append the new data to that skb. However, the code that checks for available space in the skb is flawed: ''' copy = size_goal - skb->len ''' The types of the variables involved are: ''' copy: ssize_t (s64 on 64-bit systems) size_goal: int skb->len: unsigned int ''' Due to C's type promotion rules, the signed size_goal is converted to an unsigned int to match skb->len before the subtraction. The result is an unsigned int. When this unsigned int result is then assigned to the s64 copy variable, it is zero-extended, preserving its non-negative value. Consequently, copy is always >= 0. Assume we are sending 2GB of data and size_goal has been adjusted to a value smaller than skb->len. The subtract

debian
около 1 месяца назад

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

github
около 1 месяца назад

In the Linux kernel, the following vulnerability has been resolved: tcp: Correct signedness in skb remaining space calculation Syzkaller reported a bug [1] where sk->sk_forward_alloc can overflow. When we send data, if an skb exists at the tail of the write queue, the kernel will attempt to append the new data to that skb. However, the code that checks for available space in the skb is flawed: ''' copy = size_goal - skb->len ''' The types of the variables involved are: ''' copy: ssize_t (s64 on 64-bit systems) size_goal: int skb->len: unsigned int ''' Due to C's type promotion rules, the signed size_goal is converted to an unsigned int to match skb->len before the subtraction. The result is an unsigned int. When this unsigned int result is then assigned to the s64 copy variable, it is zero-extended, preserving its non-negative value. Consequently, copy is always >= 0. Assume we are sending 2GB of data and size_goal has been adjusted to a value smaller than skb->len. The subtr...

EPSS

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

7.3 High

CVSS3

7.1 High

CVSS2