[scr265482] ip_tunnel.c

Hi: 
	I found that the GRE tunnel in same case can cause integer overflow in ip_tunnel.c:397
   
Cause of the problem:
  	When tpi->seq less than tunnel->i_seqno, the packet will be droped. 

How to recurrence problem
	1. Create an tunnel use kernel GRE module.
    2. Use the tunnel to send packets for awile.
    3.Reboot one site of the tunnel. 
    4. Communication interrupted 


		if (tunnel->parms.i_flags&TUNNEL_SEQ) {
		if (!(tpi->flags&TUNNEL_SEQ) ||
		    (tunnel->i_seqno && (s32)(ntohl(tpi->seq) - tunnel->i_seqno) < 0)) {    /**Here is the trouble code* /
			tunnel->dev->stats.rx_fifo_errors++;
			tunnel->dev->stats.rx_errors++;
			goto drop;
		}
		tunnel->i_seqno = ntohl(tpi->seq) + 1;
	}
    
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Integer Overflow in ip_tunnel.c in Ubuntu Linux kernel GRE ALL kernel 
version allows attacker to Denial of Service via reboot one end of the 
tunnel

Could you please clarify whether this affects only Ubuntu, or potentially affects other Linux distributions? ip_tunnel.c is present in the Linux kernel in all distributions and is maintained at:

  http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/net/ipv4/ip_tunnel.c

You should provide your evidence of an integer overflow, such as source code or crash tracing.

If you are reporting an Ubuntu issue, please see:

  https://wiki.ubuntu.com/SecurityTeam/FAQ#Contact

about how to file a Private Security bug in Launchpad.

If you are reporting an issue affecting the Linux kernel in general, please contact:

  security@kernel.org

You can also include:

  netdev@vger.kernel.org

if the report is public. If you need to subscribe, see:

  http://vger.kernel.org/vger-lists.html#netdev

- --
CVE Assignment Team
M/S M300, 202 Burlington Road, Bedford, MA 01730 USA [ A PGP key is available for encrypted communications at
  http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJYNeETAAoJEHb/MwWLVhi26RcP/R38S6V0LFGPHOTFNjTapcnV
RPKycC/lOCGjQehDAUkhxxTwolJpJF3RWeI+KL/hOvxA+LP3B3YeYdoYnQyZ6SqI
8J+zz5vV5mCP3olKYynO4S32bBn8rZiwoWsFWPaC4ILmoQFTLZiDbH6ji3DrHewm
OwrTysyC1a7clOuIM3BaPl3Ra0qMHsgR2b16gYMEdi/B1Ya3oLY7MVLTB2AixA9F
BB/aQjFMICfchEF39uQslU3jJd+SPuayLvceiKIvqFqBt1D8Kt2rBamzMmI5MC3M
ZbVBNfXde1MxqlV2WjUzl8KFj2l1zG7IlH1rcRes+6ZI3VaJnbv9Jyi6oc9QzMQc
nFRg9sH/DzD3g40bh2zRBtLqkQeTxxkg3JvaFc2OC2MaxMiobQCso926d4pFxTmd
+x8wP7E/nKvd4+E09/bep/v0+mEOxfSDICNGO/7gBOU4wKZ6IyaNftfe5Q1zDaxv
M3vWI6VqTFx32wY7TE69AHIH7X7WvzsBi7BLj2RHGFg2hwS7n80A1t4BcdYjPdSh
feFxfVH5gGAaG3Bm4jJOCKe5+vRwuJGjnox2+vQvUrD9v+vx0z1D5ooO8Ms2MLnT
kKL7BKhcntcoLJ3TUI09I2HZBSh7R3homgFhgrpbDHd0YjaW6XgqHjAr8piKEToK
V6jChR0YzXTkTlw1jYlE
=z0ta
-----END PGP SIGNATURE-----

On Wed, Nov 23, 2016 at 6:47 PM, Liyang Yu (于立洋1) [off-list ref] wrote:

Hi:
        I found that the GRE tunnel in same case can cause integer overflow in ip_tunnel.c:397

Cause of the problem:
        When tpi->seq less than tunnel->i_seqno, the packet will be droped.

How to recurrence problem
        1. Create an tunnel use kernel GRE module.
    2. Use the tunnel to send packets for awile.
    3.Reboot one site of the tunnel.
    4. Communication interrupted

What do you mean by "reboot one site of the tunnel"?

If you mean something like delete and create it again,
it has nothing related to integer overflow, the tunnel->o_seqno
will restart from 0 and the tunnel->i_seqno will remain as it is
since we can't detect the interruption of the tunnel traffic.
If so, the following patch could help?

diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index 5719d6b..2738ff2 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c

@@ -277,6 +277,7 @@ static struct net_device

*__ip_tunnel_create(struct net *net,
        tunnel = netdev_priv(dev);
        tunnel->parms = *parms;
        tunnel->net = net;
+       tunnel->o_seqno = UINT_MAX;

        err = register_netdevice(dev);
        if (err)

Yeah，I means that recreate the tunnel again, 
But I don’t think the patch can fix the bug. It only can make the first packet received successed. And the follow packet will droped also.
In function __gre_xmit  line 366 
  tunnel->o_seqno++;

If you restart from UINT_MAX, the 'o_seqno' of second packet will return to 0 again. 

BTW:
   Can you read Chinese? :)

On Wed, Nov 23, 2016 at 6:47 PM, Liyang Yu (于立洋1) [off-list ref] wrote:

Hi:
        I found that the GRE tunnel in same case can cause integer 
overflow in ip_tunnel.c:397

Cause of the problem:
        When tpi->seq less than tunnel->i_seqno, the packet will be droped.

How to recurrence problem
        1. Create an tunnel use kernel GRE module.
    2. Use the tunnel to send packets for awile.
    3.Reboot one site of the tunnel.
    4. Communication interrupted

What do you mean by "reboot one site of the tunnel"?

If you mean something like delete and create it again, it has nothing related to integer overflow, the tunnel->o_seqno will restart from 0 and the tunnel->i_seqno will remain as it is since we can't detect the interruption of the tunnel traffic.
If so, the following patch could help?

diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c index 5719d6b..2738ff2 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c

@@ -277,6 +277,7 @@ static struct net_device *__ip_tunnel_create(struct net *net,
        tunnel = netdev_priv(dev);
        tunnel->parms = *parms;
        tunnel->net = net;
+       tunnel->o_seqno = UINT_MAX;

        err = register_netdevice(dev);
        if (err)

On Wed, Nov 23, 2016 at 11:45 PM, Liyang Yu (于立洋1) [off-list ref] wrote:

Yeah，I means that recreate the tunnel again,
But I don’t think the patch can fix the bug. It only can make the first packet received successed. And the follow packet will droped also.
In function __gre_xmit  line 366
  tunnel->o_seqno++;

If you restart from UINT_MAX, the 'o_seqno' of second packet will return to 0 again.

The first packet after restart: o_seqno == UINT_MAX, the other end: i_seqno = 0
The second packet after restart: o_seqno == 0, the other end: i_seqno = 1

So traffic should be back to normal.

UINT_MAX is also what RFC suggests.