linux-kernel - Re: IP ID check (flush_id) in inet_gro

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 for Android: free password hash cracker in your pocket

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

Message-ID: <1467089829.6850.181.camel@edumazet-glaptop3.roam.corp.google.com>
Date:	Tue, 28 Jun 2016 06:57:09 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Tan Xiaojun <tanxiaojun@...wei.com>
Cc:	davem@...emloft.net, kuznet@....inr.ac.ru, jmorris@...ei.org,
	yoshfuji@...ux-ipv6.org, kaber@...sh.net, aduyck@...antis.com,
	hkchu@...gle.com, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: IP ID check (flush_id) in inet_gro_receive is necessary or
 not？

On Tue, 2016-06-28 at 12:40 +0800, Tan Xiaojun wrote:
> Hi everyone,
> 
> 	I'm sorry to bother you. But I was confused.
> 
> 	The IP ID check (flush_id) in inet_gro_receive is only used by
> tcp_gro_receive, and in tcp_gro_receive we have tcphdr check to ensure
> the order of skbs,
> 	like below:
> 
> 	flush |= (__force int)(th->ack_seq ^ th2->ack_seq);
> 	flush |= (ntohl(th2->seq) + skb_gro_len(p)) ^ ntohl(th->seq);
> 
> 	So if I remove the IP ID check in inet_gro_receive, there will be a
> problem ? And under what circumstances ?

You probably missed a recent patch ?

commit 1530545ed64b42e87acb43c0c16401bd1ebae6bf
Author: Alexander Duyck <aduyck@...antis.com>
Date:   Sun Apr 10 21:44:57 2016 -0400

    GRO: Add support for TCP with fixed IPv4 ID field, limit tunnel IP ID values
    
    This patch does two things.
    
    First it allows TCP to aggregate TCP frames with a fixed IPv4 ID field.  As
    a result we should now be able to aggregate flows that were converted from
    IPv6 to IPv4.  In addition this allows us more flexibility for future
    implementations of segmentation as we may be able to use a fixed IP ID when
    segmenting the flow.
    
    The second thing this does is that it places limitations on the outer IPv4
    ID header in the case of tunneled frames.  Specifically it forces the IP ID
    to be incrementing by 1 unless the DF bit is set in the outer IPv4 header.
    This way we can avoid creating overlapping series of IP IDs that could
    possibly be fragmented if the frame goes through GRO and is then
    resegmented via GSO.
    
    Signed-off-by: Alexander Duyck <aduyck@...antis.com>
    Signed-off-by: David S. Miller <davem@...emloft.net>