Date: Thu, 22 Sep 2022 08:45:01 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [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 Message-ID: <bug-264257-7501-PzRZ0vPksq@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-264257-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-264257-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264257 --- 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=3D1" was a workaround, c= ould you confirm, please? The workaround was "net.inet.tcp.rfc6675_pipe=3D0" for bug 254244, to disab= le "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 fr= om 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 erran= eous 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 previou= sly 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.=20 This day-zero issue (most likely affecting / having affected all BSD derived TCP stacks with active SACK) is fixed in FreeBSD with=20 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 wh= ich segments are sent.=20 (A regression in MAIN was also found during looking closely at the test cas= es - one of which would not fully validate the expected state, but that is not related directly to this problem really). --=20 You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-264257-7501-PzRZ0vPksq>