Date: Mon, 11 Jul 2022 15:51:02 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 265154] tcp: syncache_expand() potential race Message-ID: <bug-265154-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D265154 Bug ID: 265154 Summary: tcp: syncache_expand() potential race Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: kp@freebsd.org With 'options RSS' set the 'pf:syncookie:forward' test case often fails. The behaviour is not consistent, but it is reproducible at least 50% of the time. The failure mode is that the TCP connection is established (full SYN/SYN+ACK/ACK) exchange, but the first data packet receives a RST in response. Up to that point the exchange is identical between working and failing connections. Within the same setup (i.e. without re-creating or re-configuring jails) the connection will sometimes succeed and sometimes f= ail. The test forwards a TCP connection, terminating on a vnet jail on the same host. Because pf's syncookie feature is enabled the code path passes through pf_send(), which calls a swi, transmitting the packet from (potentially) a different CPU. This appears to be due to a race condition in syncache_expand(), where we remove the sync cache entry (`TAILQ_REMOVE(&sch->sch_bucket, sc, sc_hash);`) prior to actually opening the connection through syncache_socket() (i.e. inserting the inpcb through in_pcbconnect()). If the race condition is triggered, we end up not finding the inpcb for the= now open connection, instead trying to look up the connection in the syncache w= hen the first data packet arrives, failing to find it and resetting the entire connection. --=20 You are receiving this mail because: 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-265154-227>