File : dtls.c
Function : handle_alert() (line ~4517) and dtls_destroy_peer() (line ~2205)
When a DTLS peer sends a fatal alert or close_notify, the handle_alert() function removes the peer from the hash table via DEL_PEER() , then calls dtls_destroy_peer() which attempts to remove the same peer again . This double removal corrupts the uthash hash table and can lead to crashes or undefined behavior.
The DEL_PEER macro expands to HASH_DELETE() , which removes an entry from the uthash hash table. When called twice on the same peer:
- First call : Correctly removes the peer from the hash table
- Second call : Operates on an entry that is no longer in the hash table
The HASH_DELETE_HH implementation in uthash.h does not check if the entry is actually in the table before attempting removal. This leads to:
Corrupted hash table bucket chains
Incorrect num_items counter
Potential use-after-free if memory is reallocated between calls
Possible NULL pointer dereference in edge cases
Please confirm whether this is a bug or an intentional design that I haven't understood.
File : dtls.c
Function : handle_alert() (line ~4517) and dtls_destroy_peer() (line ~2205)
When a DTLS peer sends a fatal alert or close_notify, the handle_alert() function removes the peer from the hash table via DEL_PEER() , then calls dtls_destroy_peer() which attempts to remove the same peer again . This double removal corrupts the uthash hash table and can lead to crashes or undefined behavior.
The DEL_PEER macro expands to HASH_DELETE() , which removes an entry from the uthash hash table. When called twice on the same peer:
The HASH_DELETE_HH implementation in uthash.h does not check if the entry is actually in the table before attempting removal. This leads to:
Corrupted hash table bucket chains
Incorrect num_items counter
Potential use-after-free if memory is reallocated between calls
Possible NULL pointer dereference in edge cases
Please confirm whether this is a bug or an intentional design that I haven't understood.