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

exploitDog

redhat логотип

CVE-2024-26752

Опубликовано: 03 апр. 2024
Источник: redhat
CVSS3: 5.5

Описание

In the Linux kernel, the following vulnerability has been resolved: l2tp: pass correct message length to ip6_append_data l2tp_ip6_sendmsg needs to avoid accounting for the transport header twice when splicing more data into an already partially-occupied skbuff. To manage this, we check whether the skbuff contains data using skb_queue_empty when deciding how much data to append using ip6_append_data. However, the code which performed the calculation was incorrect: ulen = len + skb_queue_empty(&sk->sk_write_queue) ? transhdrlen : 0; ...due to C operator precedence, this ends up setting ulen to transhdrlen for messages with a non-zero length, which results in corrupted packets on the wire. Add parentheses to correct the calculation in line with the original intent.

A vulnerability was found in the l2tp_ip6_sendmsg() function in the Linux kernel. An incorrect length calculation due to operator precedence issues can cause packet corruption and lead to communication issues.

Отчет

Red Hat Enterprise Linux 8 and 9 are not affected by this vulnerability.

Затронутые пакеты

ПлатформаПакетСостояниеРекомендацияРелиз
Red Hat Enterprise Linux 6kernelNot affected
Red Hat Enterprise Linux 7kernelNot affected
Red Hat Enterprise Linux 7kernel-rtNot affected
Red Hat Enterprise Linux 8kernelNot affected
Red Hat Enterprise Linux 8kernel-rtNot affected
Red Hat Enterprise Linux 9kernelNot affected
Red Hat Enterprise Linux 9kernel-rtNot affected

Показывать по

Дополнительная информация

Статус:

Moderate
Дефект:
CWE-130
https://bugzilla.redhat.com/show_bug.cgi?id=2273219kernel: l2tp: pass correct message length to ip6_append_data

5.5 Medium

CVSS3

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

CVSS3: 5.5
ubuntu
около 1 года назад

In the Linux kernel, the following vulnerability has been resolved: l2tp: pass correct message length to ip6_append_data l2tp_ip6_sendmsg needs to avoid accounting for the transport header twice when splicing more data into an already partially-occupied skbuff. To manage this, we check whether the skbuff contains data using skb_queue_empty when deciding how much data to append using ip6_append_data. However, the code which performed the calculation was incorrect: ulen = len + skb_queue_empty(&sk->sk_write_queue) ? transhdrlen : 0; ...due to C operator precedence, this ends up setting ulen to transhdrlen for messages with a non-zero length, which results in corrupted packets on the wire. Add parentheses to correct the calculation in line with the original intent.

CVSS3: 5.5
nvd
около 1 года назад

In the Linux kernel, the following vulnerability has been resolved: l2tp: pass correct message length to ip6_append_data l2tp_ip6_sendmsg needs to avoid accounting for the transport header twice when splicing more data into an already partially-occupied skbuff. To manage this, we check whether the skbuff contains data using skb_queue_empty when deciding how much data to append using ip6_append_data. However, the code which performed the calculation was incorrect: ulen = len + skb_queue_empty(&sk->sk_write_queue) ? transhdrlen : 0; ...due to C operator precedence, this ends up setting ulen to transhdrlen for messages with a non-zero length, which results in corrupted packets on the wire. Add parentheses to correct the calculation in line with the original intent.

CVSS3: 5.5
debian
около 1 года назад

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

CVSS3: 5.5
github
около 1 года назад

In the Linux kernel, the following vulnerability has been resolved: l2tp: pass correct message length to ip6_append_data l2tp_ip6_sendmsg needs to avoid accounting for the transport header twice when splicing more data into an already partially-occupied skbuff. To manage this, we check whether the skbuff contains data using skb_queue_empty when deciding how much data to append using ip6_append_data. However, the code which performed the calculation was incorrect: ulen = len + skb_queue_empty(&sk->sk_write_queue) ? transhdrlen : 0; ...due to C operator precedence, this ends up setting ulen to transhdrlen for messages with a non-zero length, which results in corrupted packets on the wire. Add parentheses to correct the calculation in line with the original intent.

CVSS3: 5.5
fstec
больше 1 года назад

Уязвимость компонента l2tp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

5.5 Medium

CVSS3