summaryrefslogtreecommitdiff
path: root/CREDITS
diff options
context:
space:
mode:
authorTom Parkin <tparkin@katalix.com>2024-02-20 12:21:56 +0000
committerPaolo Abeni <pabeni@redhat.com>2024-02-22 10:42:17 +0100
commit359e54a93ab43d32ee1bff3c2f9f10cb9f6b6e79 (patch)
tree6c268c27eb84c99869ee93ebb0715ec815c0b968 /CREDITS
parent9ff27943060c0282ca14e40f05c2b907edc85a42 (diff)
downloadlwn-359e54a93ab43d32ee1bff3c2f9f10cb9f6b6e79.tar.gz
lwn-359e54a93ab43d32ee1bff3c2f9f10cb9f6b6e79.zip
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. Fixes: 9d4c75800f61 ("ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data()") Cc: David Howells <dhowells@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Tom Parkin <tparkin@katalix.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/20240220122156.43131-1-tparkin@katalix.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Diffstat (limited to 'CREDITS')
0 files changed, 0 insertions, 0 deletions