Que peut expliquer la corruption de tas lors d’un appel à free ()?

Je suis en train de déboguer un crash depuis plusieurs jours, qui se produit dans les profondeurs d’OpenSSL (discussion avec les responsables ici ). J’ai pris un peu de temps pour enquêter, alors je vais essayer de rendre cette question intéressante et informative.

Tout d’abord et pour donner un peu de contexte, mon échantillon minimal reproduisant le crash est le suivant:

#include  #include  #include  #include  #include  #include  int main() { ERR_load_crypto_ssortingngs(); OpenSSL_add_all_algorithms(); ENGINE_load_builtin_engines(); EC_GROUP* group = EC_GROUP_new_by_curve_name(NID_sect571k1); EC_GROUP_set_point_conversion_form(group, POINT_CONVERSION_UNCOMPRESSED); EC_KEY* eckey = EC_KEY_new(); EC_KEY_set_group(eckey, group); EC_KEY_generate_key(eckey); BIO* out = BIO_new(BIO_s_file()); BIO_set_fp(out, stdout, BIO_NOCLOSE); PEM_write_bio_ECPrivateKey(out, eckey, NULL, NULL, 0, NULL, NULL); // <= CRASH. } 

Fondamentalement, ce code génère une clé à courbe elliptique et tente de la sortir sur stdout . Un code similaire peut être trouvé dans openssl.exe ecparam et sur les wikis en ligne. Cela fonctionne très bien sous Linux (valgrind ne rapporte aucune erreur). Il se bloque uniquement sur Windows (Visual Studio 2013 – x64). Je me suis assuré que les temps d’exécution appropriés étaient liés à ( /MD dans mon cas, pour toutes les dépendances).

Ne craignant aucun mal, j’ai recompilé OpenSSL dans x64-debug (cette fois, tout en liant tout dans /MDd ), puis /MDd parcouru le code pour trouver le jeu d’instructions incriminé. Ma recherche m’a conduit à ce code (dans le fichier tasn_fre.c d’OpenSSL):

• Comment se débarrasser de l’avertissement de dépréciation de hash_map g ++?
• Programme avec le constructeur «noexcept» accepté par gcc, rejeté par clang
• getline () sautant en premier même après clear ()
• L’incrémentation d’un iterator d’entrée modifiable invalide-t-elle les anciennes valeurs d’iterator?
• Contrôle utilisateur C # .NET dans l’application native. Problèmes liés à la chaîne de ressources

 static void asn1_item_combine_free(ASN1_VALUE **pval, const ASN1_ITEM *it, int combine) { // ... some code, not really relevant. tt = it->templates + it->tcount - 1; for (i = 0; i tcount; tt--, i++) { ASN1_VALUE **pseqval; seqtt = asn1_do_adb(pval, tt, 0); if (!seqtt) continue; pseqval = asn1_get_field_ptr(pval, seqtt); ASN1_template_free(pseqval, seqtt); } if (asn1_cb) asn1_cb(ASN1_OP_FREE_POST, pval, it, NULL); if (!combine) { OPENSSL_free(*pval); // <= CRASH OCCURS ON free() *pval = NULL; } // Some more code... } 

Pour ceux qui ne sont pas trop familiers avec OpenSSL et ses routines ASN.1, en gros, ceci for -loop fait en sorte qu’il passe par tous les éléments d’une séquence (en commençant par le dernier élément) et les “supprime” (plus à ce sujet plus tard) .

Juste avant que le crash ne se produise, une séquence de 3 éléments est supprimée (à *pval , qui est 0x00000053379575E0 ). En regardant la mémoire, on peut voir les choses suivantes se produire:

La séquence est longue de 12 octets, chaque élément étant long de 4 octets (dans ce cas, 2 , 5 et 10 ). A chaque itération de boucle, les éléments sont “supprimés” par OpenSSL (dans ce contexte, ni delete ni free sont appelés: ils sont simplement définis avec une valeur spécifique). Voici à quoi ressemble la mémoire après une itération:

Le dernier élément ici a été défini sur ff ff ff 7f ce qui, je suppose, est le moyen utilisé par OpenSSL pour garantir qu’aucune information clé ne fuit lorsque la mémoire est désallouée ultérieurement.

Juste après la boucle (et avant l’appel de OPENSSL_free() ), la mémoire est la suivante:

Tous les éléments ont été réglés sur ff ff ff 7f , asn1_cb étant NULL , aucun appel n’est effectué. La prochaine chose qui se passe est l’appel à OPENSSL_free(*pval) .

Cet appel à free() sur ce qui semble être une mémoire valide et allouée échoue et provoque l’interruption de l’exécution avec le message “HEAP CORRUPTION DETECTED” .

Curieux à ce sujet, je me suis accroché à malloc , realloc et free (comme le permet OpenSSL) pour s’assurer que ce n’était pas une mémoire double libre ou libre sur jamais allouée. Il s’avère que la mémoire à 0x00000053379575E0 est en réalité un bloc de 12 octets qui a été effectivement alloué (et n’a jamais été libéré auparavant).

Je ne sais pas trop ce qui se passe ici: d’après mes recherches, il semble que free() échoue sur un pointeur qui était normalement renvoyé par malloc() . En plus de cela, cet emplacement de mémoire était en train d’être écrit dans quelques instructions avant sans aucun problème qui confirme l’hypothèse que la mémoire soit allouée correctement.

Je sais qu’il est difficile, voire impossible, de déboguer à distance sans toutes les informations, mais je n’ai aucune idée de ce que devraient être mes prochaines étapes.

Ma question est donc la suivante: comment exactement “HEAP CORRUPTION” est-il détecté par le débogueur de Visual Studio? Quelles en sont toutes les causes possibles lorsqu’il provient d’un appel à free() ?

• Utilisation d’un compilateur différent dans Visual Studio
• lire un entier 32 bits à partir d’un fichier binary
• Boost codes d’erreur description lisible par l’homme
• Existe-t-il un fichier de grammaire C ++ fonctionnel pour ANTLR?
• fonction membre statique et sécurité du fil

 int CRYPTO_set_mem_ex_functions(void *(*m) (size_t, const char *, int), void *(*r) (void *, size_t, const char *, int), void (*f) (void *)) 

 if (!combine) { *pval = OPENSSL_malloc(it->size); // <== The allocation is here. if (!*pval) goto memerr; memset(*pval, 0, it->size); asn1_do_lock(pval, 0, it); asn1_enc_init(pval, it); } for (i = 0, tt = it->templates; i < it->tcount; tt++, i++) { pseqval = asn1_get_field_ptr(pval, tt); if (!ASN1_template_new(pseqval, tt)) goto memerr; } 

 if (!combine) *pval = NULL;