All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steffen Klassert <steffen.klassert@secunet.com>
To: Xin Long <lucien.xin@gmail.com>
Cc: network dev <netdev@vger.kernel.org>, <davem@davemloft.net>,
	Paolo Abeni <pabeni@redhat.com>, Florian Westphal <fw@strlen.de>
Subject: Re: [PATCH net] udp: fix a skb extensions leak
Date: Mon, 30 Mar 2020 10:29:29 +0200	[thread overview]
Message-ID: <20200330082929.GG13121@gauss3.secunet.de> (raw)
In-Reply-To: <e17fe23a0a5f652866ec623ef0cde1e6ef5dbcf5.1585213585.git.lucien.xin@gmail.com>

On Thu, Mar 26, 2020 at 05:06:25PM +0800, Xin Long wrote:
> On udp rx path udp_rcv_segment() may do segment where the frag skbs
> will get the header copied from the head skb in skb_segment_list()
> by calling __copy_skb_header(), which could overwrite the frag skbs'
> extensions by __skb_ext_copy() and cause a leak.
> 
> This issue was found after loading esp_offload where a sec path ext
> is set in the skb.
> 
> On udp tx gso path, it works well as the frag skbs' extensions are
> not set. So this issue should be fixed on udp's rx path only and
> release the frag skbs' extensions before going to do segment.

Are you sure that this affects only the RX path? What if such
a packet is forwarded? Also, I think TCP has the same problem.

> 
> Reported-by: Xiumei Mu <xmu@redhat.com>
> Fixes: cf329aa42b66 ("udp: cope with UDP GRO packet misdirection")
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> ---
>  include/net/udp.h | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/include/net/udp.h b/include/net/udp.h
> index e55d5f7..7bf0ca5 100644
> --- a/include/net/udp.h
> +++ b/include/net/udp.h
> @@ -486,6 +486,10 @@ static inline struct sk_buff *udp_rcv_segment(struct sock *sk,
>  	if (skb->pkt_type == PACKET_LOOPBACK)
>  		skb->ip_summed = CHECKSUM_PARTIAL;
>  
> +	if (skb_has_frag_list(skb) && skb_has_extensions(skb))
> +		skb_walk_frags(skb, segs)
> +			skb_ext_put(segs);

If a skb in the fraglist has a secpath, it is still valid.
So maybe instead of dropping it here and assign the one
from the head skb, we could just keep the secpath. But
I don't know about other extensions. I've CCed Florian,
he might know a bit more about other extensions. Also,
it might be good to check if the extensions of the GRO
packets are all the same before merging.


  parent reply	other threads:[~2020-03-30  8:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-26  9:06 [PATCH net] udp: fix a skb extensions leak Xin Long
2020-03-26  9:28 ` Xin Long
2020-03-30  4:54 ` David Miller
2020-03-30  8:29 ` Steffen Klassert [this message]
2020-03-30 16:13   ` Xin Long
2020-03-30 16:13     ` Florian Westphal
2020-03-30 13:27 ` Florian Westphal
2020-03-30 13:45   ` Steffen Klassert
2020-03-30 14:11     ` Florian Westphal
2020-03-30 14:39       ` Steffen Klassert
2020-03-30 16:14   ` Xin Long

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=20200330082929.GG13121@gauss3.secunet.de \
    --to=steffen.klassert@secunet.com \
    --cc=davem@davemloft.net \
    --cc=fw@strlen.de \
    --cc=lucien.xin@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.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.