Skip to content

Fix uninitialized sizes returned when close notify is disabled

Michael Catanzaro requested to merge mcatanzaro/#91 into master

I'm hitting a crash loading a particular webpage that terminates a secure WebSocket connection uncleanly, without sending the TLS close notify. Turns out we have no tests for whether disabling truncation errors with g_tls_connection_set_require_close_notify() actually works or not, which is why I missed this regression. (libsoup always disables required close notify, while our tests never do.)

When close notify is not required and the connection is closed uncleanly, we are supposed to return 0 bytes read to indicate EOF. But instead we are returning uninitialized memory. Since WebKit needs to pass the data returned from the network process to the web process via IPC, it attempts to allocate a memory buffer, passing uninitialized memory for the size to allocate. On my computer, this results in crashes when bmalloc attempts to allocate e.g. ~127 TB of memory or die. Sadly, my desktop doesn't have this much RAM.

Anyway, GTlsConnectionBase is already careful to return -1 whenever the status of the op is anything other than G_TLS_CONNECTION_BASE_SUCCESS. So we only have to worry about ensuring the nread/nwrote parameters are initialized to 0 if there is an underlying error from GnuTLS/OpenSSL. The problem occurs because the current code expects nread/nwrote to never be read if there is an error, but it doesn't realize we can ignore underlying errors and return G_TLS_CONNECTION_BASE_SUCCESS anyway, as we do when we ignore GNUTLS_E_PREMATURE_TERMINATION when close notify is not required.

Fixes #91 (closed)

Merge request reports