[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200102112731.299b5fe4@hermes.lan>
Date: Thu, 2 Jan 2020 11:27:31 -0800
From: Stephen Hemminger <stephen@...workplumber.org>
To: Ttttabcd <ttttabcd@...tonmail.com>
Cc: Netdev <netdev@...r.kernel.org>,
David Miller <davem@...emloft.net>,
"kuznet@....inr.ac.ru" <kuznet@....inr.ac.ru>,
"yoshfuji@...ux-ipv6.org" <yoshfuji@...ux-ipv6.org>
Subject: Re: [PATCH] fragment: Improved handling of incorrect IP fragments
On Tue, 31 Dec 2019 01:19:27 +0000
Ttttabcd <ttttabcd@...tonmail.com> wrote:
> @@ -267,8 +278,6 @@ static int ip6_frag_reasm(struct frag_queue *fq, struct sk_buff *skb,
> payload_len = ((skb->data - skb_network_header(skb)) -
> sizeof(struct ipv6hdr) + fq->q.len -
> sizeof(struct frag_hdr));
> - if (payload_len > IPV6_MAXPLEN)
> - goto out_oversize;
You can not safely drop this check.
With recursive fragmentation it is possible that the initial payload ends
up exceeding the maximum packet length.
Powered by blists - more mailing lists