, can the tunnel work well? haw-haw, is this condition
able to meet
a CVE.
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 s
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 sequenc
you means that SMP ( Symmetric Multi Processing )?
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, t
27; 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) wrote:
> Hi:
> I found that the GRE tunnel in same case can cause integer
> overflow in ip_tunnel.c:397
>
> Cause of the 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
