>Bug is in the RFC for not describing how both ends would magically
>synchronize, with a sequence protocol which is unidirectional, with no ACK
>packets or whatever going back.
>With no description, it means that RFC author(s) never considered one side of
>the tunnel could die and restart.
>Cont
Yeah you got it. Great!!!
On Thu, Nov 24, 2016 at 9:11 PM, Liyang Yu (于立洋1) wrote:
>> Please test my patch since you can reproduce it.
>
> Thanks cong, but Eric had said: "Really, this is not something that
> can be solved by using 'a different initial sequence number'"
> So I do
On Thu, Nov 24, 2016 at 9:11 PM, Liyang Yu (于立洋1) wrote:
>> Please test my patch since you can reproduce it.
>
> Thanks cong, but Eric had said: "Really, this is not something that
> can be solved by using 'a different initial sequence number'"
> So I don't think it's nessary to t
On Thu, Nov 24, 2016 at 7:52 PM, Liyang Yu (于立洋1) wrote:
> I accept that the issue is not a CVE candidate. But it's a bug isn't it
Bug is in the RFC for not describing how both ends would magically synchronize,
with a sequence protocol which is unidirectional, with no ACK packets
or whatever go
On Thu, Nov 24, 2016 at 5:39 PM, Liyang Yu (于立洋1) wrote:
> BTW:
>
>Which RFC suggests UINT_MAX as GRE sequence number? Can you show me?
https://tools.ietf.org/html/rfc2890
"The receiver maintains the sequence number value of the last successfully
decapsulated packet. Upon establishment of
I accept that the issue is not a CVE candidate. But it's a bug isn't it
Thank you for your suggestions, about the format of mail, and not next time.
Everything has its meaning. If sequence number is a joke, why the guys put it
into RFC , even implemented the feature.
And if you means that
On Thu, Nov 24, 2016 at 5:39 PM, Liyang Yu (于立洋1) 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 secur...@kernel.org from CC, n
On Wed, Nov 23, 2016 at 11:45 PM, Liyang Yu (于立洋1) 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_
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 pac
On Wed, Nov 23, 2016 at 6:47 PM, Liyang Yu (于立洋1) 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
>
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 tu
11 matches
Mail list logo
