You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
mbedtls version: 2.7.6 (is however still present in newest version)
In a firmware of mine, I have observed a crash (HardFault) when printing the status of the memory buffer using the function mbedtls_memory_buffer_alloc_status(). The crash log is as follows:
The firmware is fairly complex and features multiple threads doing handshakes or encrypting stuff. So it can definitely happen that there concurrent calls to the buffer allocation functions. However, I have also implemented the MBEDTLS_THREADING_ALT functions using the mbed-os provided Mutex class and called mbedtls_threading_set_alt() accordingly. This mutex layer works, I have tested it independently.
The crash takes place (by looking at the PC) at the last line
What you can see from the log is while printing the free list of the heap, it suddenly jumps to pointers it shouldn't. Note how there's there's a break from PTR( 536928324) to PTR( 68) (with an allocation size which exceeds the amount of memory the device has).
When looking at the code it seems to me that this is a race which occurs when calling mbedtls_memory_buffer_alloc_status(). All the allocation function lock the heap.mutex while modifying the heap (see e.g. buffer_alloc_calloc_mutexed()). however, the buffer alloc status function does not. It just iterates through the linked list and follows every pointer. This behavior is still in there in newest code.
mbedtls_fprintf( stderr, "All memory de-allocated in stack buffer\n" );
}
else
{
mbedtls_fprintf( stderr, "Memory currently allocated:\n" );
debug_chain();
}
}
Thus I think my observed crash was caused by a race in which a free() operation took place while printing the buffer, and thus it printed a correct NEXT pointer but when assigning cur = cur->next_free; the value was already modified to some other value.
I thus propse to add the following code at the beginning and end of the function:
I have tried to reproduce this exact crash but haven't succeeded. Triggering / loosing this race seems to be quite hard, but as my log file shows, possible.
Issue request type
[ ] Question
[ ] Enhancement
[X] Bug
The text was updated successfully, but these errors were encountered:
Description
In a firmware of mine, I have observed a crash (HardFault) when printing the status of the memory buffer using the function
mbedtls_memory_buffer_alloc_status()
. The crash log is as follows:The firmware is fairly complex and features multiple threads doing handshakes or encrypting stuff. So it can definitely happen that there concurrent calls to the buffer allocation functions. However, I have also implemented the
MBEDTLS_THREADING_ALT
functions using the mbed-os providedMutex
class and calledmbedtls_threading_set_alt()
accordingly. This mutex layer works, I have tested it independently.The crash takes place (by looking at the
PC
) at the last lineWhere it does a dereference of the
hdr
pointer.What you can see from the log is while printing the free list of the heap, it suddenly jumps to pointers it shouldn't. Note how there's there's a break from
PTR( 536928324)
toPTR( 68)
(with an allocation size which exceeds the amount of memory the device has).When looking at the code it seems to me that this is a race which occurs when calling
mbedtls_memory_buffer_alloc_status()
. All the allocation function lock theheap.mutex
while modifying the heap (see e.g.buffer_alloc_calloc_mutexed()
). however, the buffer alloc status function does not. It just iterates through the linked list and follows every pointer. This behavior is still in there in newest code.mbed-crypto/library/memory_buffer_alloc.c
Lines 509 to 530 in 150d577
Thus I think my observed crash was caused by a race in which a
free()
operation took place while printing the buffer, and thus it printed a correctNEXT
pointer but when assigningcur = cur->next_free;
the value was already modified to some other value.I thus propse to add the following code at the beginning and end of the function:
I have tried to reproduce this exact crash but haven't succeeded. Triggering / loosing this race seems to be quite hard, but as my log file shows, possible.
Issue request type
The text was updated successfully, but these errors were encountered: