Page MenuHomeFreeBSD

Properly handle a closed TLS socket with pending receive data.
ClosedPublic

Authored by jhb on Jul 27 2020, 10:33 PM.

Details

Summary

If the remote end closes a TLS socket and the socket buffer still
contains not-yet-decrypted TLS records but no decrypted TLS records,
soreceive needs to block or fail with EWOULDBLOCK. Previously it was
trying to return data and dereferencing a NULL pointer.

Test Plan
  • reproduced panic during post-commit KTLS testing using openssl s_time
  • used a debug printf to ensure the EWOULDBLOCK case was being hit during the s_time test

Diff Detail

Repository
rS FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

jhb requested review of this revision.Jul 27 2020, 10:33 PM
jhb created this revision.

My original KTLS patchset had some other changes in soreceive_generic() to check for M_NOTREADY that I left out. One of those changes happened to protect against this case (it had added an m != NULL check before the goto dontblock) which is why I never saw this during my pre-commit testing. I chose the immediate goto even though it's a larger patch as I think the meaning is clearer this way (if you have any valid data, always return it) and it also matches the previous block above for so_error. I also chose to put the tlsdcc and tlscc checks under KERN_TLS.

This revision is now accepted and ready to land.Jul 29 2020, 2:40 PM