Étrange pile d'appels, cela pourrait-il poser un problème d'utilisation d'Assl par asio?

Question

J'ai cette pile d'appels étrange et je suis perplexe pour comprendre pourquoi.

Il me semble qu'asio appelle open ssl's read et obtient ensuite une valeur de retour négative (-37).

Asio semble alors essayer de l’utiliser dans la fonction memcpy.

La fonction à l'origine de cette pile d'appels est utilisée des centaines de milliers de fois sans cette erreur.

Cela n'arrive que rarement, environ une fois par semaine.

ulRead = (boost::asio::read(spCon->socket(), boost::asio::buffer(_requestHeader, _requestHeader.size()), boost::asio::transfer_at_least(_requestHeader.size()), error_));

Notez que la taille de l'en-tête de la demande est toujours de 3 octets exactement.

Quelqu'un pourrait-il nous éclairer sur les raisons possibles?

Remarque: j'utilise boost asio 1.36

Voici le crash de la pile d'appels se produisant dans la mémoire en raison de l'énorme "compte":

Answer 1

Un rapide coup d'œil sur evp_lib.c montre qu'il tente d'extraire une longueur du contexte de chiffrement et, dans votre cas, obtient une très mauvaise valeur (tm). Il utilise ensuite cette valeur pour copier une chaîne (qui effectue la memcpy). Je suppose que quelque chose détruit votre chiffrement, qu'il s'agisse d'un problème de sécurité des threads ou de la lecture de davantage d'octets dans une mémoire tampon que celle autorisée.

Source pertinente :

int EVP_CIPHER_set_asn1_iv(EVP_CIPHER_CTX *c, ASN1_TYPE *type)
{
int i=0,j;

if (type != NULL)
    {
    j=EVP_CIPHER_CTX_iv_length(c);
    OPENSSL_assert(j <= sizeof c->iv);
    i=ASN1_TYPE_set_octetstring(type,c->oiv,j);
    }
return(i);
}