02.08.2024 10:02, Michael Tokarev wrote:
23.07.2024 16:10, Peter Maydell wrote:
Coverity points out that in our handling of the property
RPI_FWREQ_SET_CUSTOMER_OTP we have a potential overflow. This
happens because we read start_num and number from the guest as
unsigned 32 bit integers, but the
23.07.2024 16:10, Peter Maydell wrote:
Coverity points out that in our handling of the property
RPI_FWREQ_SET_CUSTOMER_OTP we have a potential overflow. This
happens because we read start_num and number from the guest as
unsigned 32 bit integers, but then the variable 'n' we use as a loop
counte
On 24/7/24 14:31, Peter Maydell wrote:
On Wed, 24 Jul 2024 at 08:06, Philippe Mathieu-Daudé wrote:
Hi Peter,
On 23/7/24 15:10, Peter Maydell wrote:
Coverity points out that in our handling of the property
RPI_FWREQ_SET_CUSTOMER_OTP we have a potential overflow. This
happens because we read
On Wed, 24 Jul 2024 at 08:06, Philippe Mathieu-Daudé wrote:
>
> Hi Peter,
>
> On 23/7/24 15:10, Peter Maydell wrote:
> > Coverity points out that in our handling of the property
> > RPI_FWREQ_SET_CUSTOMER_OTP we have a potential overflow. This
> > happens because we read start_num and number from
Hi Peter,
On 23/7/24 15:10, Peter Maydell wrote:
Coverity points out that in our handling of the property
RPI_FWREQ_SET_CUSTOMER_OTP we have a potential overflow. This
happens because we read start_num and number from the guest as
unsigned 32 bit integers, but then the variable 'n' we use as a
Coverity points out that in our handling of the property
RPI_FWREQ_SET_CUSTOMER_OTP we have a potential overflow. This
happens because we read start_num and number from the guest as
unsigned 32 bit integers, but then the variable 'n' we use as a loop
counter as we iterate from start_num to start_n
