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>] [day] [month] [year] [list]

Message-ID: <CANn89iJKmO0oiJjw5y59B_DdA+4xzkbtVDWnz3NA8UvoSYt4Pw@mail.gmail.com>
Date:   Thu, 24 Nov 2016 18:27:43 -0800
From:   Eric Dumazet <edumazet@...gle.com>
To:     Liyang Yu (于立洋1) <yuliyang1@...com>
Cc:     Cong Wang <xiyou.wangcong@...il.com>,
        "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 Thu, Nov 24, 2016 at 5:39 PM, Liyang Yu (于立洋1) <yuliyang1@...com> wrote:
>
>
>
>
>
>
>
> BTW:
>
>    Which RFC suggests UINT_MAX as GRE sequence number?  Can you show me?
>
>
>
>
>
>


RFC 2890

In any cases, this is absolutely not a security issue nor a CVE candidate.
Please remove security@...nel.org from CC, no need to spam security guys,
they have enough on their plate.

Please send text messages, no HTML is allowed on netdev

Nobody sane uses GRE sequence numbers, precisely because GRE has
no documented way to synchronize the source and destination of the tunnel.
Basically, if you use GRE sequence numbers, you must re-start other side
of the tunnel if one side had to restart, or risk dropping up to 2^31 packets.

Really, this is not something that can be solved by using
'a different initial sequence number'

linux GRE sequence number support is a joke, it does not support SMP
for a start.



>
>
>
> 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.