netdev - 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <f209ec7a-7d14-0112-e906-69c016298aa5@science.ru.nl>
Date:   Mon, 22 May 2017 17:24:55 +0200
From:   Paul Fiterau Brostean <p.fiterau-brostean@...ence.ru.nl>
To:     netdev@...r.kernel.org
Subject: Inconsistency in ipv4/tcp_input regarding sequence number
 acceptability condition

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.

Download attachment "linux_model.pdf" of type "application/pdf" (216985 bytes)