Page MenuHomeFreeBSD

tcp: remove an invalid KASSERT
ClosedPublic

Authored by tuexen on Jun 29 2025, 9:21 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Oct 11, 11:30 PM
Unknown Object (File)
Sat, Oct 11, 11:30 PM
Unknown Object (File)
Sat, Oct 11, 11:30 PM
Unknown Object (File)
Sat, Oct 11, 2:13 PM
Unknown Object (File)
Sep 15 2025, 7:21 AM
Unknown Object (File)
Sep 13 2025, 6:53 AM
Unknown Object (File)
Sep 12 2025, 9:35 PM
Unknown Object (File)
Sep 12 2025, 3:47 PM
Subscribers

Details

Summary

Since TCP endpoints in the TIME-WAIT state are no longer special, allow them to be switched over to the default stack.

Reported by: syzbot+902d31bb0e68a1e8c088@syzkaller.appspotmail.com

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Looks I am missing the context. Given the fact that the socket is in TCPS_TIME_WAIT while switching to the default stack, was this assert a day one issue that was not test covered before? Or was this panic caused by recent changes?

In D51090#1166124, @cc wrote:

Looks I am missing the context. Given the fact that the socket is in TCPS_TIME_WAIT while switching to the default stack, was this assert a day one issue that was not test covered before? Or was this panic caused by recent changes?

Before D36398 TCP endpoints in the TIME-WAIT state had a minimal state. This did not include a reference to a TCP function block. Therefore, there was a check in tcp_ctloutput_set(), which made switching the TCP function block in the TIME-WAIT state impossible by an early return with EINVAL. This means that the KASSERT() was correct before D36398. After D36398, the TIME-WAIT state is not special anymore and consequently, the check was removed in D36400. Since D36400 the bug does exist, I think.
The reason it was reported only recently by syzkaller, is that syzkaller often uses only local TCP connections. The following is an example of the test programs:

# https://syzkaller.appspot.com/bug?id=5ac24a3c5711973c287882c9539f095ac817a309
# See https://goo.gl/kgGztJ for information about syzkaller reproducers.
#{"repeat":true,"procs":1,"slowdown":1,"sandbox":"","sandbox_arg":0,"close_fds":false}
r0 = socket(0x2, 0x1, 0x0)
bind$inet(r0, &(0x7f00000001c0)={0x10, 0x2, 0x2}, 0x10)
setsockopt$inet_tcp_TCP_FUNCTION_BLK(r0, 0x6, 0x2000, &(0x7f0000000080)={'rack\x00', 0x6}, 0x24)
connect$inet(r0, &(0x7f0000000400)={0x10, 0x2, 0x2, @loopback}, 0x10)
sendmsg$unix(r0, &(0x7f0000002580)={0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x180}, 0x20104)
setsockopt$inet_tcp_TCP_FUNCTION_BLK(r0, 0x6, 0x2000, &(0x7f0000000380)={'freebsd\x00', 0x1}, 0x24)

I am sure that syzkaller was running these kind of tests in the past, but only since D51069 local endpoints actually enter the TIME-WAIT state and therefore the bug was uncovered.

This revision is now accepted and ready to land.Jun 30 2025, 11:20 PM

Thanks for the elaboration. Looks good to me now.

This revision was automatically updated to reflect the committed changes.