https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 08 Oct 2026 04:41:51 +0000 https://cve.radiocsirt.org/vuln/cve-2024-26752 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>l2tp: pass correct message length to ip6_append_data</p> <p>l2tp_ip6_sendmsg needs to avoid accounting for the transport header twice when splicing more data into an already partially-occupied skbuff.</p> <p>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.</p> <p>However, the code which performed the calculation was incorrect:</p> <p>ulen = len + skb_queue_empty(&amp;sk-&gt;sk_write_queue) ? transhdrlen : 0;</p> <p>...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.</p> <p>Add parentheses to correct the calculation in line with the original intent.</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>l2tp: pass correct message length to ip6_append_data</p> <p>l2tp_ip6_sendmsg needs to avoid accounting for the transport header twice when splicing more data into an already partially-occupied skbuff.</p> <p>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.</p> <p>However, the code which performed the calculation was incorrect:</p> <p>ulen = len + skb_queue_empty(&amp;sk-&gt;sk_write_queue) ? transhdrlen : 0;</p> <p>...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.</p> <p>Add parentheses to correct the calculation in line with the original intent.</p> https://cve.radiocsirt.org/vuln/cve-2024-26752