netdev - Re: Inconsistency in ipv4/tcp_input regarding sequence number acceptability condition

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

Message-ID: <1495472401.6465.56.camel@edumazet-glaptop3.roam.corp.google.com>
Date:   Mon, 22 May 2017 10:00:01 -0700
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Paul Fiterau Brostean <p.fiterau-brostean@...ence.ru.nl>
Cc:     netdev@...r.kernel.org
Subject: Re: Inconsistency in ipv4/tcp_input regarding sequence number
 acceptability condition

On Mon, 2017-05-22 at 17:24 +0200, Paul Fiterau Brostean wrote:
> Hello esteemed Linux Developers,
> 
> My name is Paul, I am a PhD student. I sent a different question a while 
> back to the netdev mailing list, and never got a response. This question 
> should be a lot easier to address. While doing experiments on the Linux 
> TCP stack as part of a research project, I have stumbled upon a 
> potential inconsistency with the RFC specification.
> 
> The Linux TCP stack considers a received sequence number as in-window or 
> acceptable, if the sequence number of the segment is between the 
> expected sequence number and the expected sequence number plus the size 
> of the receive window. Naturally, the lower bound is included in the 
> range. What's a bit weird is that the upper bound of this range is also 
> considered in-window. This is evident both from my experiments and from 
> the code 
> (http://elixir.free-electrons.com/linux/v4.11/source/net/ipv4/tcp_input.c#L3985).
> 
> The RFC states that the upper bound shouldn't be considered. If we look 
> at: https://tools.ietf.org/html/rfc793#page-26  the acceptability 
> conditions exclude  RCV.NXT+RCV.WND (where applicable). Is there a 
> reason for Linux including the upper bound? Or can this be fixed?
> 
> Analyzing FreeBSD, they seem to have adopted the RFC standard, and have 
> not included the upper bound.
> 
> 
> As an aside, my work involves automatic inference of models from 
> software components. We obtained models for FreeBSD and Linux TCP 
> clients and comparing them we were able to spot this minor difference. 
> The models we can obtain automatically abstract away from many 
> complexities (like timing, re-transmissions), and only consider socket 
> calls and flags/seq/ack numbers (payloads are 0). I attached a Linux 
> model to give you an example. If you look at the ESTABLISHED state, 
> receiving a RST  segment (R), prompts the Linux system to respond with a 
> challenge ACK segment (A) if the sequence number (p1) satisfies the 
> condition: 'r1+win >=p1 && r1<p1' where 'r1' is the expected sequence 
> number and 'win' is the receive window size.
> 
> Thanks for your attention, Paul.


Hi Paul

I am planning to send a fix for this.

( Internal Google Bug Id : 37204158,  filled April 10th )

I did replied to you, but I got other more urgent work to do.

Thanks.