[Bug 264257] [tcp] Panic: Fatal trap 12: page fault while in kernel mode (if_io_tqg_4) - m_copydata ... at /usr/src/sys/kern/uipc_mbuf.c:659

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264257

--- Comment #99 from Richard Scheffenegger <rscheff@freebsd.org> ---
(In reply to Marek Zarychta from comment #98)
> It looks like setting "net.inet.tcp.rfc6675_pipe=1" was a workaround, could you confirm, please?

The workaround was "net.inet.tcp.rfc6675_pipe=0" for bug 254244, to disable
"SACK rescue retransmissions".

> This issue looks similar to the already fixed bug 254244.

Similar yes, but not identical.

In Bug 254244, it was an oversight on my part, to deal with the final <FIN> bit
in the sequence number space, if a rescue retransmission is to be done after
the stack had already sent this <FIN>.

The implicit assumption is, that at the tail end of a TCP session, only a
single <FIN>, at one specific sequence number exists - as it should be.

However, the complex of bug 260393, bug 263445 and this bug 264257 comes from
an issue which existed "forever", but never, or extremely rarely manifested
itself as a server-side panic. It does have some potential to lead to erraneous
bytes at the tail end of a tcp session, which, depending on the application
using the data, may lead to client side data inconsistencies.

That issue is, that under specific circumstances, a TCP session will sent
multiple <FIN> at advancing sequence numbers, and "overwriting" the previously
sent <FIN> with a (not fully) arbitrary data byte.

In once instance, logging showed up to 6 consecutive <FIN>s, each at a new
position - but even just two such <FIN> at consecutive positions are
problematic. 

This day-zero issue (most likely affecting / having affected all BSD derived
TCP stacks with active SACK) is fixed in FreeBSD with 
https://reviews.freebsd.org/D36626

While investigating further, two more bugs showed up:
https://reviews.freebsd.org/D36631
https://reviews.freebsd.org/D36637

but these do not corrupt the tcpcb state, or lead to erraneous transmission of
different information at the same sequence number - only affect when and which
segments are sent. 

(A regression in MAIN was also found during looking closely at the test cases -
one of which would not fully validate the expected state, but that is not
related directly to this problem really).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.