netdev - Re: 答复: [scr265482] ip

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAM_iQpUQ0F6hOuPFAVPJUhYKy1sYNr-FLxYgKJ15eDSmgWqKGg@mail.gmail.com>
Date:   Thu, 24 Nov 2016 09:38:22 -0800
From:   Cong Wang <xiyou.wangcong@...il.com>
To:     Liyang Yu (于立洋1) <yuliyang1@...com>
Cc:     "security@...nel.org" <security@...nel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "cve-request@...re.org" <cve-request@...re.org>
Subject: Re: 答复: [scr265482] ip_tunnel.c

On Wed, Nov 23, 2016 at 11:45 PM, Liyang Yu (于立洋1) <yuliyang1@...com> 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.