Page MenuHomeFreeBSD

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

Authored by jhb on Mon, Jul 27, 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.Mon, Jul 27, 10:33 PM
jhb created this revision.
jhb added a comment.Mon, Jul 27, 10:38 PM

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.

np accepted this revision.Wed, Jul 29, 2:40 PM
This revision is now accepted and ready to land.Wed, Jul 29, 2:40 PM
This revision was automatically updated to reflect the committed changes.