This blog post explains the code: <a href="http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html" rel="nofollow">http://blog.existentialize.com/diagnosis-of-the-openssl-hear...</a>
I'm sort of surprised an allocation occurs every time the heartbeat is sent. That is a lot of trips to the heap.<p>I'm not very familiar with how TLS heartbeats are implemented, but I wonder if the buffer could have just been alloc'd once when the connection was created.
I like how those bounds checks (the ifs) have no curly braces, as if that Apple security bug didn't wake people up about such trivial opportunities for bugs.
I wonder if any of the existing static code analyzers would have found this?<p>PVS-Studio checks some open source projects and posts part of the results on their blog. I did a search and found that they did take a look at OpenSSL in 2012.<p><a href="http://www.viva64.com/en/b/0183/" rel="nofollow">http://www.viva64.com/en/b/0183/</a><p>And Coverity: <a href="https://scan.coverity.com/projects/294" rel="nofollow">https://scan.coverity.com/projects/294</a>
<p><pre><code> /* Read type and payload length first */
</code></pre>
And now this is actually the second thing the code does, not the first.