Byte received by UART may be received as corrupted, i.e. having a different value than received, if a glitch (a short 0 pulse) occurs during second half of stopbit. There's no indication that this occured in the UART's flags, RXNE is set as normally.

This issue pertains probably to the "new" UART used in all STM32 since 'F0/'F3. It is documented in an erratum e.g. for 'G0B1, but was observed e.g. also on 'L431 which errata don't contain this erratum. It takes time until ST propagates a new erratum to all relevant models' errata.

What could be the possible mechanism of this problem? UARTs should stop the Rx process by sampling the stopbit at its middle, as due to possible timing mismatch between transmitter and receiver, this may be in reality the end of stopbit and it's just time to start to wait for the next frame's startbit downgoing (leading) edge. The just received frame should be transferred to the Rx buffer at this point, and the RXNE flag should be risen.

Here, transfer of the received frame appears to be delayed for some reason. The glitch (a short 0 pulse) during startbit detection should be ignored; however, it appears that it also through some error in design impacts the frame which is still in the receiver's shift register (or its equivalent), and then the corrupted frame is transferred to the Rx buffer.

How can such glitch happen? UART transmitters which can control a transceiver (e.g. RS485) often switch the transceiver's direction at the middle of last transmitted byte (again, to accomodate for possible timing mismatch between parties on a shared bus and prevent collision). Some less-than-perfect combination of transceivers and their loads (e.g. cables) may result in such short unwanted glitch to be generated. UARTs are normally designed to ignore short glitches, so such conditions usually go unnoticed.