Hello,
I have filed an issue but thought I would post this here for reference, this bug took me quite a while to hunt down and hope to save others time possibly:
I have found a memory-safety defect in EEPROM_Emul on STM32U5 128-bit flash-line config.
Config:
- FLASH_LINES_128B enabled
- EE_ACCESS_32BITS enabled
Issue:
- EE_ReadVariable32bits() passes a single EE_DATA_TYPE buffer:
Core/EEPROM_Emul/Core/eeprom_emul.c:758, :762
- In FLASH_LINES_128B mode, ReadVariable() writes two words:
Core/EEPROM_Emul/Core/eeprom_emul.c:1184, :1185
- This writes beyond the caller’s single-word buffer and can corrupt stack/register state (we observed HardFault with corrupted stacked PC).
Why “wrong API usage” is not a valid dismissal:
1) The API is publicly exposed in this build mode (Core/EEPROM_Emul/Core/eeprom_emul.h:126 with FLASH_LINES_128B APIs also present at :130).
2) An exported API must not corrupt memory under any call pattern; unsupported combinations must fail explicitly.
3) This component already uses status-return semantics, so unsupported mode should return an error, not perform out-of-bounds write.
Expected fix:
- Either make 32/16/8-bit read APIs unavailable when FLASH_LINES_128B is enabled (compile-time guard),
- Or keep them supported by using a local 2-word buffer internally and returning only the intended value,
- Or return a clear error code for unsupported mode before touching caller buffers.
Requested:
- Confirm defect
- Provide upstream patch/version where fixed
