Add heartbeat extension bounds check

This blog post explains the code: <a href="http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html" rel="nofollow">http:&#x2F;&#x2F;blog.existentialize.com&#x2F;diagnosis-of-the-openssl-hear...</a>

I&#x27;m sort of surprised an allocation occurs every time the heartbeat is sent. That is a lot of trips to the heap.<p>I&#x27;m not very familiar with how TLS heartbeats are implemented, but I wonder if the buffer could have just been alloc&#x27;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&#x27;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:&#x2F;&#x2F;www.viva64.com&#x2F;en&#x2F;b&#x2F;0183&#x2F;</a><p>And Coverity: <a href="https://scan.coverity.com/projects/294" rel="nofollow">https:&#x2F;&#x2F;scan.coverity.com&#x2F;projects&#x2F;294</a>

1 + 3 + padding and 1 + 3 + 16 are repeated. I suspect the magic 16 is actually just the padding too.

<p><pre><code> &#x2F;* Read type and payload length first *&#x2F; </code></pre> And now this is actually the second thing the code does, not the first.

I wonder if OpenSSL will get some code clean up courtesy of the extra eyes that are now on the code?

HN front page is heartbleeding, I counted at least 8 stories.