Netdev List
 help / color / mirror / Atom feed
From: Sabrina Dubroca <sd@queasysnail.net>
To: Ttttabcd <ttttabcd@protonmail.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: I found a strange place while reading “net/ipv6/reassembly.c”
Date: Wed, 15 Aug 2018 15:16:41 +0200	[thread overview]
Message-ID: <20180815131641.GA24411@bistromath.localdomain> (raw)
In-Reply-To: <SFcjXy7yNtGx0prpq73gVredyTRO62MxkhifUjhdZT6AqXpetrRFT9AtzwqflOGcpsqVg9CiO-mNEr8uT24SyYenCwoGTz8x1sB6a-tNv7w=@protonmail.com>

2018-08-15, 04:38:29 +0000, Ttttabcd wrote:
> Hello everyone who develops the kernel.
> 
> At the beginning I was looking for the source author, but his email
> address has expired, so I can only come here to ask questions.
> 
> The problem is in the /net/ipv6/reassembly.c file, the author is
> Pedro Roque.
> 
> I found some strange places when I read the code for this file
> (Linux Kernel version 4.18).
> 
> In the "/net/ipv6/reassembly.c"
> 
> In the function "ip6_frag_queue"
> 
> 	offset = ntohs(fhdr->frag_off) & ~0x7;
> 	end = offset + (ntohs(ipv6_hdr(skb)->payload_len) -
> 			((u8 *)(fhdr + 1) - (u8 *)(ipv6_hdr(skb) + 1)));
> 
> 	if ((unsigned int)end > IPV6_MAXPLEN) {
> 		*prob_offset = (u8 *)&fhdr->frag_off - skb_network_header(skb);
> 		return -1;
> 	}
> 
> Here the length of the payload is judged.

This check is based on the fragment currently being processed, and
only considers the reassembled payload.

> And in the function "ip6_frag_reasm"
> 

Re-adding the comment that comes just above this:

  	/* Unfragmented part is taken from the first segment. */
> 	payload_len = ((head->data - skb_network_header(head)) -
> 		       sizeof(struct ipv6hdr) + fq->q.len -
> 		       sizeof(struct frag_hdr));
> 	if (payload_len > IPV6_MAXPLEN)
> 		goto out_oversize;

This considers the reassembled payload (ie, as above) *and* any
extension headers that might come before it.


> 	......
> 	out_oversize:
> 		net_dbg_ratelimited("ip6_frag_reasm: payload len = %d\n", payload_len);
> 		goto out_fail;
> 
> Here also judges the length of the payload.
> 
> Judged the payload length twice.
> 
> I tested that the code in the label "out_oversize:" does not execute
> at all, because it has been returned in "ip6_frag_queue".

If you try again with a routing header, I think you'll see it trigger.

> Unless I comment out the code that judge the payload length in the
> function "ip6_frag_queue", the code labeled "out_oversize:" can be
> executed.
> 
> So, is this repeated?

-- 
Sabrina

      reply	other threads:[~2018-08-15 16:08 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-15  4:38 I found a strange place while reading “net/ipv6/reassembly.c” Ttttabcd
2018-08-15 13:16 ` Sabrina Dubroca [this message]

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=20180815131641.GA24411@bistromath.localdomain \
    --to=sd@queasysnail.net \
    --cc=netdev@vger.kernel.org \
    --cc=ttttabcd@protonmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox