I have in the code reading of clear-on-read register (mapped to memory, not part of the CPU) in place that may be interrupted, but the interrupt will always return to the same context.
I was thinking that if the CPU pipeline reads the clear-on-read register, but before executing the instruction the CPU will be interrupted, when it will return it will re-read the clear-on-read register which is now cleared due to the previous read that was interrupted.
Is this scenario is valid? if yes, how it should be handled?
If you have memory-mapped I/O registers where reading them has side effects (such as clearing), then you need to indicate to the CPU that this range of addresses is "volatile". Accesses to such addresses must not be cached, loaded speculatively, reordered with other side effects, etc.
How you do this is CPU-dependent. For instance, on ARMv8, there is a bit in each page table entry that can be set to designate it as "device" memory, which is uncached and so on. x86 has page attribute tables which replace the earlier feature of memory type range registers. For other CPUs, you will need to refer to the vendor's documentation.
Once you have done so, then interrupts are not a concern. When an interrupt occurs, either your load has completed, in which case the loaded value is already in the destination CPU register and the load will not be repeated after the interrupt is handled, or else it has not taken place at all and will begin after the interrupt handler returns.