All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Tom Parkin <tparkin@katalix.com>
Cc: netdev@vger.kernel.org, David Howells <dhowells@redhat.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH net] l2tp: pass correct message length to ip6_append_data
Date: Wed, 21 Feb 2024 14:43:16 +0000	[thread overview]
Message-ID: <20240221144316.GA722610@kernel.org> (raw)
In-Reply-To: <20240220122156.43131-1-tparkin@katalix.com>

On Tue, Feb 20, 2024 at 12:21:56PM +0000, Tom Parkin wrote:
> 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>

> ---
> This issue was uncovered by Debian build-testing for the
> golang-github-katalix-go-l2tp package[1].
> 
> It seems 9d4c75800f61 has been backported to the linux-6.1.y stable
> kernel (and possibly others), so I think this fix will also need
> backporting.
> 
> The bug is currently seen on at least Debian Bookworm, Ubuntu Jammy, and 
> Debian testing/unstable.

In that case perhaps this is appropriate - citing the patch that 9d4c75800f61
tried to fix?

	Fixes: a32e0eec7042 ("l2tp: introduce L2TPv3 IP encapsulation support for IPv6")


> 
> Unfortunately tests using "ip l2tp" and which focus on dataplane
> transport will not uncover this bug: it's necessary to send a packet
> using an L2TPIP6 socket opened by userspace, and to verify the packet on
> the wire.  The l2tp-ktest[2] test suite has been extended to cover this.
> 
> [1]. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063746
> [2]. https://github.com/katalix/l2tp-ktest

...

  reply	other threads:[~2024-02-21 14:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-20 12:21 [PATCH net] l2tp: pass correct message length to ip6_append_data Tom Parkin
2024-02-21 14:43 ` Simon Horman [this message]
2024-02-22 10:00 ` patchwork-bot+netdevbpf
  -- strict thread matches above, loose matches on Subject: below --
2024-02-20 12:21 Tom Parkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240221144316.GA722610@kernel.org \
    --to=horms@kernel.org \
    --cc=dhowells@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=tparkin@katalix.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.