We'll start with the simple answer - It is *bad* practice to write/erase flash with interrupts enabled.
A flash array is not able to be read when it is being programmed or erased, that is *no* part of the array can be read, not just the word/sector in question.
In the old days, when external flash was the norm, this meant that the flash programming code had to be executed from RAM since the flash device would output a status word whilst in a programming or erase state.
Parts like the STM32 with an internal flash array and the flash controller attached to a syncronous bus do not have this restriction, instead the bus can be stalled during a program or erase operation. Of course this does mean that no instructions can be executed during this period so interrupts might as well be disabled as they cannot be serviced.
Erasing a flash block is also a very slow operation, IIRC the array used in the STM32F1xx takes about 40mS to erase a page. Given this large stall I suspect that the problem you are seeing is an overflow of some sort due to interrupts not being processed in a timely manner.
Probably not the answer you wanted but I hope it explains why it is happening.
As an aside, I don't know your application, how much data you want to write or how frequently it need to change but the flash core in the STM32 has two separate arrays: the main program array and a small info block. Part of the small info block is available for user data storage. You do need to be very careful how you manage this block though as it contains the 'read-protect' flag and inadvertant set/clear of this flag can trigger a mass erase of the main flash area.