Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Sat, 15 Dec 2018 11:54:43 -0800 (PST)
Message-Id: <20181215.115443.1744275952795502150.davem@davemloft.net>
To:     mkubecek@suse.cz
Cc:     netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
        posk@google.com, eric.dumazet@gmail.com, gfigueira@suse.com
Subject: Re: [PATCH net v2] net: ipv4: do not handle duplicate fragments as
 overlapping
From:   David Miller <davem@davemloft.net>
In-Reply-To: <20181213162332.E426FE1116@unicorn.suse.cz>
References: <20181213162332.E426FE1116@unicorn.suse.cz>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

From: Michal Kubecek <mkubecek@suse.cz>
Date: Thu, 13 Dec 2018 17:23:32 +0100 (CET)

> Since commit 7969e5c40dfd ("ip: discard IPv4 datagrams with overlapping
> segments.") IPv4 reassembly code drops the whole queue whenever an
> overlapping fragment is received. However, the test is written in a way
> which detects duplicate fragments as overlapping so that in environments
> with many duplicate packets, fragmented packets may be undeliverable.
> 
> Add an extra test and for (potentially) duplicate fragment, only drop the
> new fragment rather than the whole queue. Only starting offset and length
> are checked, not the contents of the fragments as that would be too
> expensive. For similar reason, linear list ("run") of a rbtree node is not
> iterated, we only check if the new fragment is a subset of the interval
> covered by existing consecutive fragments.
> 
> Fixes: 7969e5c40dfd ("ip: discard IPv4 datagrams with overlapping segments.")
> Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
> 
> v2: instead of an exact check iterating through linear list of an rbtree
> node, only check if the new fragment is subset of the "run" (suggested
> by Eric Dumazet)

Applied and queued up for -stable, thank you.