Description
When using ihex_mem_copy(), there are several possible memory access bugs involved.
The base address of the record is checked to lie within the target memory range specified by the dst and n parameters. However, the record length in bytes is not considered, so writing the whole record data may end up past the end of allocated memory (verified with valgrind).
In addition, record data is always copied in four-byte blocks, caused by the use of uint32_t pointers. This may lead to writing even more data than specified in the record length, in case the latter was not a multiple of four.
To correct these issues, care needs to be taken to still correctly implement endianness / byte order swapping. So far I have a simple fix to avoid the first memory access violation, but a better copying approach is needed. I will update this issue with a pull request once I have a first draft.