[PATCH] rtc/mc146818rtc: fix QEMU crash when time runs backwards

[PATCH] rtc/mc146818rtc: fix QEMU crash when time runs backwards

[shenjiatong]

Loosen restriction on computed lost_tick. When QEMU's rtc_clock is set
to host, the walltime is used for mc146818rtc which requires computed
lost_tick to be strictly non-negative. But host walltime could possibly
run backwards, for example, configured by NTP service. Under such
circumstances QEMU process could crash unexpectly. This situation is
easy to reproduce for Windows 2012/2016 guests.
---
 hw/rtc/mc146818rtc.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/hw/rtc/mc146818rtc.c b/hw/rtc/mc146818rtc.c
index 8631386b9f..04185eb6e9 100644
--- a/hw/rtc/mc146818rtc.c
+++ b/hw/rtc/mc146818rtc.c
@@ -173,8 +173,7 @@ static void periodic_timer_update(MC146818RtcState *s, int64_t current_time,
         next_periodic_clock = muldiv64(s->next_periodic_time,
                                 RTC_CLOCK_RATE, NANOSECONDS_PER_SECOND);
         last_periodic_clock = next_periodic_clock - old_period;
-        lost_clock = cur_clock - last_periodic_clock;
-        assert(lost_clock >= 0);
+        lost_clock = MAX(cur_clock - last_periodic_clock, 0);
     }
 
     /*
-- 
2.34.1

Re: [PATCH] rtc/mc146818rtc: fix QEMU crash when time runs backwards

[Michael S. Tsirkin]

On Thu, Nov 13, 2025 at 11:02:11AM +0800, shenjiatong wrote:
> Loosen restriction on computed lost_tick. When QEMU's rtc_clock is set
> to host, the walltime is used for mc146818rtc which requires computed
> lost_tick to be strictly non-negative. But host walltime could possibly
> run backwards, for example, configured by NTP service. Under such
> circumstances QEMU process could crash unexpectly. This situation is
> easy to reproduce for Windows 2012/2016 guests.

Looks like this feel through the cracks.
The patch lacks your Signed off by certifying the DCO.
Could you pls confirm that?

> ---
>  hw/rtc/mc146818rtc.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/hw/rtc/mc146818rtc.c b/hw/rtc/mc146818rtc.c
> index 8631386b9f..04185eb6e9 100644
> --- a/hw/rtc/mc146818rtc.c
> +++ b/hw/rtc/mc146818rtc.c
> @@ -173,8 +173,7 @@ static void periodic_timer_update(MC146818RtcState *s, int64_t current_time,
>          next_periodic_clock = muldiv64(s->next_periodic_time,
>                                  RTC_CLOCK_RATE, NANOSECONDS_PER_SECOND);
>          last_periodic_clock = next_periodic_clock - old_period;
> -        lost_clock = cur_clock - last_periodic_clock;
> -        assert(lost_clock >= 0);
> +        lost_clock = MAX(cur_clock - last_periodic_clock, 0);
>      }
>  
>      /*
> -- 
> 2.34.1
> 
> 
> 

Re: [PATCH] rtc/mc146818rtc: fix QEMU crash when time runs backwards

[Michael S. Tsirkin]

On Thu, Nov 13, 2025 at 11:02:11AM +0800, shenjiatong wrote:
> Loosen restriction on computed lost_tick. When QEMU's rtc_clock is set
> to host, the walltime is used for mc146818rtc which requires computed
> lost_tick to be strictly non-negative. But host walltime could possibly
> run backwards, for example, configured by NTP service. Under such
> circumstances QEMU process could crash unexpectly.

could crash -> crashes on an assert

remove "unexpectly."

> This situation is
> easy to reproduce for Windows 2012/2016 guests.

hmm what does it matter what is the guest?


Pls describe a fix shortly here.


And please follow standard practice to submit changes,
such as read and sign off on the DCO.


> ---
>  hw/rtc/mc146818rtc.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/hw/rtc/mc146818rtc.c b/hw/rtc/mc146818rtc.c
> index 8631386b9f..04185eb6e9 100644
> --- a/hw/rtc/mc146818rtc.c
> +++ b/hw/rtc/mc146818rtc.c
> @@ -173,8 +173,7 @@ static void periodic_timer_update(MC146818RtcState *s, int64_t current_time,
>          next_periodic_clock = muldiv64(s->next_periodic_time,
>                                  RTC_CLOCK_RATE, NANOSECONDS_PER_SECOND);
>          last_periodic_clock = next_periodic_clock - old_period;
> -        lost_clock = cur_clock - last_periodic_clock;
> -        assert(lost_clock >= 0);
> +        lost_clock = MAX(cur_clock - last_periodic_clock, 0);
>      }
>  
>      /*
> -- 
> 2.34.1
> 
> 
>