956c9e063d
case The actual input / output buffer overhead is only 301 instead of 512. This requires a proper check on the padding_idx to prevent out of bounds reads. Previously a remote party could potentially trigger an access error and thus stop the application when sending a malicious packet having MAX_CONTENT_LEN of data, 32 bytes of MAC and a decrypted padlen of . This would result in reading from in_ctr + 13 + 32 + MAX_CONTENT_LEN - 1 - 1 for 256 bytes (including fake padding check). Or 13 + 32 bytes over the buffer length. We now reset padding_idx to 0, if it's clear that it will never be a valid padding (padlen > msg_len || msg_len + padlen + 256 > buffer_len) |
||
---|---|---|
.. | ||
polarssl | ||
.gitignore | ||
CMakeLists.txt |