All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	stable@vger.kernel.org, Zheng Li <james.z.li@ericsson.com>,
	"David S. Miller" <davem@davemloft.net>
Subject: [PATCH 4.4 14/15] ipv4: Should use consistent conditional judgement for ip fragment in __ip_append_data and ip_finish_output
Date: Fri, 11 Aug 2017 15:02:28 -0700	[thread overview]
Message-ID: <20170811220220.018875625@linuxfoundation.org> (raw)
In-Reply-To: <20170811220219.438083791@linuxfoundation.org>

4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: zheng li <james.z.li@ericsson.com>

commit 0a28cfd51e17f4f0a056bcf66bfbe492c3b99f38 upstream.

There is an inconsistent conditional judgement in __ip_append_data and
ip_finish_output functions, the variable length in __ip_append_data just
include the length of application's payload and udp header, don't include
the length of ip header, but in ip_finish_output use
(skb->len > ip_skb_dst_mtu(skb)) as judgement, and skb->len include the
length of ip header.

That causes some particular application's udp payload whose length is
between (MTU - IP Header) and MTU were fragmented by ip_fragment even
though the rst->dev support UFO feature.

Add the length of ip header to length in __ip_append_data to keep
consistent conditional judgement as ip_finish_output for ip fragment.

Signed-off-by: Zheng Li <james.z.li@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 net/ipv4/ip_output.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -923,7 +923,7 @@ static int __ip_append_data(struct sock
 
 	cork->length += length;
 	if ((skb && skb_is_gso(skb)) ||
-	    ((length > mtu) &&
+	    (((length + fragheaderlen) > mtu) &&
 	    (skb_queue_len(queue) <= 1) &&
 	    (sk->sk_protocol == IPPROTO_UDP) &&
 	    (rt->dst.dev->features & NETIF_F_UFO) && !rt->dst.header_len &&

  parent reply	other threads:[~2017-08-11 22:09 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-11 22:02 [PATCH 4.4 00/15] 4.4.82-stable review Greg Kroah-Hartman
2017-08-11 22:02 ` [PATCH 4.4 01/15] tcp: avoid setting cwnd to invalid ssthresh after cwnd reduction states Greg Kroah-Hartman
2017-08-11 22:02 ` [PATCH 4.4 02/15] net: fix keepalive code vs TCP_FASTOPEN_CONNECT Greg Kroah-Hartman
2017-08-18 11:57   ` Eddie Chapman
2017-08-11 22:02 ` [PATCH 4.4 03/15] bpf, s390: fix jit branch offset related to ldimm64 Greg Kroah-Hartman
2017-08-11 22:02 ` [PATCH 4.4 04/15] net: sched: set xt_tgchk_param par.nft_compat as 0 in ipt_init_target Greg Kroah-Hartman
2017-08-11 22:02 ` [PATCH 4.4 05/15] tcp: fastopen: tcp_connect() must refresh the route Greg Kroah-Hartman
2017-08-11 22:02 ` [PATCH 4.4 06/15] net: avoid skb_warn_bad_offload false positives on UFO Greg Kroah-Hartman
2017-08-11 22:02 ` [PATCH 4.4 07/15] packet: fix tp_reserve race in packet_set_ring Greg Kroah-Hartman
2017-08-11 22:02 ` [PATCH 4.4 08/15] revert "net: account for current skb length when deciding about UFO" Greg Kroah-Hartman
2017-08-11 22:02 ` [PATCH 4.4 09/15] revert "ipv4: Should use consistent conditional judgement for ip fragment in __ip_append_data and ip_finish_output" Greg Kroah-Hartman
2017-08-11 22:02 ` [PATCH 4.4 10/15] udp: consistently apply ufo or fragmentation Greg Kroah-Hartman
2017-08-11 22:02 ` [PATCH 4.4 11/15] sparc64: Prevent perf from running during super critical sections Greg Kroah-Hartman
2017-08-11 22:02 ` [PATCH 4.4 12/15] KVM: arm/arm64: Handle hva aging while destroying the vm Greg Kroah-Hartman
2017-08-11 22:02 ` [PATCH 4.4 13/15] mm/mempool: avoid KASAN marking mempool poison checks as use-after-free Greg Kroah-Hartman
2017-08-11 22:02 ` Greg Kroah-Hartman [this message]
2017-08-12  1:57 ` [PATCH 4.4 00/15] 4.4.82-stable review Shuah Khan
2017-08-12 12:24 ` Guenter Roeck

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=20170811220220.018875625@linuxfoundation.org \
    --to=gregkh@linuxfoundation.org \
    --cc=davem@davemloft.net \
    --cc=james.z.li@ericsson.com \
    --cc=linux-kernel@vger.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.