From: Stephen Hemminger <stephen@networkplumber.org>
To: netdev@vger.kernel.org
Subject: Fw: [Bug 211085] New: No response from TCP connection in ESTALISHED state if sending data segment with unacceptable ACK
Date: Fri, 8 Jan 2021 08:00:46 -0800 [thread overview]
Message-ID: <20210108080046.014d6924@hermes.local> (raw)
This looks like a case where some conformance test is testing a corner case in
the standard where the Linux TCP stack is not following the standard for valid reasons.
Linux behavior of silently dropping the packet would reduce DoS changes and information
leakage for MiTM attacks.
Begin forwarded message:
Date: Fri, 08 Jan 2021 08:17:40 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 211085] New: No response from TCP connection in ESTALISHED state if sending data segment with unacceptable ACK
https://bugzilla.kernel.org/show_bug.cgi?id=211085
Bug ID: 211085
Summary: No response from TCP connection in ESTALISHED state if
sending data segment with unacceptable ACK
Product: Networking
Version: 2.5
Kernel Version: 5.4.24 and upstream
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IPV4
Assignee: stephen@networkplumber.org
Reporter: alex.thresher@googlemail.com
Regression: No
We're currently failing to pass the TCP_UNACCEPTABLE_04 test from TCP/IP tests
of TC8 ECU and Network Test specification (Open Alliance). The Test
specification is freely available on the Internet.
TCP_UNACCEPTABLE_04 validates the behavior of RFC793 'Chapter 3.4.
Establishing a connection / Reset Generation (3)' (Page 36) and 'Chapter 9 -
Event Processing / SEGMENT ARRIVES / Otherwise / Check ACK field' (Page 71)
which pointed out that sending an unacceptable ACK in ESTALISHED state for
example ACK acks a data segment not yet sent should be answered with an ACK
(from RFC793 - '...must elicit only an empty acknowledgment segment containing
the current send-sequence number and an acknowledgment indicating the next
sequence number expected to be received...'). After that the segment needs to
be discarded.
Unfortunately the segment is only discarded and not confirmed by ACK. I did
some research in the TCP/IP stack and found the code which is responsible for
discarding the ACK.
It's in 'net/ipv4/tcp_input.c' in function tcp_ack currently on line 3727 of
upstream kernel.
>>/* If the ack includes data we haven't sent yet, discard
>> * this segment (RFC793 Section 3.9).
>> */
>>if (after(ack, tp->snd_nxt))
>> return -1;
Validation was done on DUT target with Kernel 5.4.24.
Let me if you need further informations.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
reply other threads:[~2021-01-08 16:03 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210108080046.014d6924@hermes.local \
--to=stephen@networkplumber.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).