All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Bader <stefan.bader@canonical.com>
To: stable <stable@vger.kernel.org>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Eric Dumazet <edumazet@google.com>,
	Sasha Levin <sashal@kernel.org>, Peter Oskolkov <posk@google.com>,
	Ben Hutchings <ben.hutchings@codethink.co.uk>,
	Andy Whitcroft <andy.whitcroft@canonical.com>,
	Greg KH <gregkh@linuxfoundation.org>
Subject: [PATCH 0/4] ipv6: frags: fixups for linux-4.4.y
Date: Wed, 29 May 2019 12:25:38 +0200	[thread overview]
Message-ID: <20190529102542.17742-1-stefan.bader@canonical.com> (raw)

While this backport proposal is based on the 4.4.y stable tree, it
might also apply in some form to any stable tree which backported

 05c0b86b96: "ipv6: frags: rewrite ip6_expire_frag_queue()"

While this made ip6_expire_frag_queue() similar to ip_exire(),
it did not follow the additional changes to ip_expire() which
were also backported:

 fa0f527358: "ip: use rb trees for IP frag queue."

 a4fd284a1f: "ip: process in-order fragments efficiently"

The former of the two not only adds handling for rb trees, but
also modifies ip_expire() to take the first skb off the queue
before using it for the sending the icmp message. This also got
rid of the need to protect the skb by incrementing its reference
count (which is the reason for the crash in ip6_expire_frag_queue()).

My first approach was do those changes in ip6_expire_frag_queue(),
but only the former of the two can be done without problems. The
latter uses code which is only locally defined in ipv4/ip_fragment.c.

This was changed upstream in 5.1 when moving code around to be shared

  c23f35d19d: "net: IP defrag: encapsulate rbtree defrag code into
               callable functions"

And while backporting that I found the two other changes which sounded
like one might want them backported, too. Maybe even more since the
second (ip: fail fast on IP defrag errors) is already partially
included in the backport of "net: ipv4: do not handle duplicate
fragments as overlapping".

Though I do realize that "net: IP defrag: encapsulate rbtree
defrag code into callable functions" is rather large and for
that reason maybe not qualifying as a stable backport.
So I would like to ask what the net-developers think about
this.

Thanks,
Stefan



0001: v4.20: ipv4: ipv6: netfilter: Adjust the frag mem limit when
             truesize changes
0002: v4.20: ip: fail fast on IP defrag errors
0003: v5.1 : net: IP defrag: encapsulate rbtree defrag code into
             callable functions
0004: n/a  : ipv6: frags: Use inet_frag_pull_head() in
             ip6_expire_frag_queue()

Jiri Wiesner (1):
  ipv4: ipv6: netfilter: Adjust the frag mem limit when truesize changes

Peter Oskolkov (2):
  ip: fail fast on IP defrag errors
  net: IP defrag: encapsulate rbtree defrag code into callable functions

Stefan Bader (1):
  ipv6: frags: Use inet_frag_pull_head() in ip6_expire_frag_queue()

 include/net/inet_frag.h                 |  16 +-
 net/ipv4/inet_fragment.c                | 293 +++++++++++++++++++++++
 net/ipv4/ip_fragment.c                  | 294 +++---------------------
 net/ipv6/netfilter/nf_conntrack_reasm.c |   8 +-
 net/ipv6/reassembly.c                   |  20 +-
 5 files changed, 359 insertions(+), 272 deletions(-)

-- 
2.17.1


             reply	other threads:[~2019-05-29 10:25 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-29 10:25 Stefan Bader [this message]
2019-05-29 10:25 ` [PATCH 1/4] ipv4: ipv6: netfilter: Adjust the frag mem limit when truesize changes Stefan Bader
2019-05-29 10:37   ` Greg KH
2019-05-29 12:31     ` Stefan Bader
2019-06-04 13:32     ` Stefan Bader
2019-05-29 10:25 ` [PATCH 2/4] ip: fail fast on IP defrag errors Stefan Bader
2019-05-29 10:25 ` [PATCH 3/4] net: IP defrag: encapsulate rbtree defrag code into callable functions Stefan Bader
2019-05-29 10:25 ` [PATCH 4/4] ipv6: frags: Use inet_frag_pull_head() in ip6_expire_frag_queue() Stefan Bader

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=20190529102542.17742-1-stefan.bader@canonical.com \
    --to=stefan.bader@canonical.com \
    --cc=andy.whitcroft@canonical.com \
    --cc=ben.hutchings@codethink.co.uk \
    --cc=edumazet@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=posk@google.com \
    --cc=sashal@kernel.org \
    --cc=stable@vger.kernel.org \
    /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.