Patch "ntp: Clamp maxerror and esterror to operating range" has been added to the 6.10-stable tree

[Sasha Levin <sashal@xxxxxxxxxx>]

This is a note to let you know that I've just added the patch titled

    ntp: Clamp maxerror and esterror to operating range

to the 6.10-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     ntp-clamp-maxerror-and-esterror-to-operating-range.patch
and it can be found in the queue-6.10 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 0be4e9a2267c0ff34ccd0bd465b7b105f6ce9814
Author: Justin Stitt <justinstitt@xxxxxxxxxx>
Date:   Fri May 17 20:22:44 2024 +0000

    ntp: Clamp maxerror and esterror to operating range
    
    [ Upstream commit 87d571d6fb77ec342a985afa8744bb9bb75b3622 ]
    
    Using syzkaller alongside the newly reintroduced signed integer overflow
    sanitizer spits out this report:
    
    UBSAN: signed-integer-overflow in ../kernel/time/ntp.c:461:16
    9223372036854775807 + 500 cannot be represented in type 'long'
    Call Trace:
     handle_overflow+0x171/0x1b0
     second_overflow+0x2d6/0x500
     accumulate_nsecs_to_secs+0x60/0x160
     timekeeping_advance+0x1fe/0x890
     update_wall_time+0x10/0x30
    
    time_maxerror is unconditionally incremented and the result is checked
    against NTP_PHASE_LIMIT, but the increment itself can overflow, resulting
    in wrap-around to negative space.
    
    Before commit eea83d896e31 ("ntp: NTP4 user space bits update") the user
    supplied value was sanity checked to be in the operating range. That change
    removed the sanity check and relied on clamping in handle_overflow() which
    does not work correctly when the user supplied value is in the overflow
    zone of the '+ 500' operation.
    
    The operation requires CAP_SYS_TIME and the side effect of the overflow is
    NTP getting out of sync.
    
    Miroslav confirmed that the input value should be clamped to the operating
    range and the same applies to time_esterror. The latter is not used by the
    kernel, but the value still should be in the operating range as it was
    before the sanity check got removed.
    
    Clamp them to the operating range.
    
    [ tglx: Changed it to clamping and included time_esterror ]
    
    Fixes: eea83d896e31 ("ntp: NTP4 user space bits update")
    Signed-off-by: Justin Stitt <justinstitt@xxxxxxxxxx>
    Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
    Cc: Miroslav Lichvar <mlichvar@xxxxxxxxxx>
    Link: https://lore.kernel.org/all/20240517-b4-sio-ntp-usec-v2-1-d539180f2b79@xxxxxxxxxx
    Closes: https://github.com/KSPP/linux/issues/354
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index 406dccb79c2b6..502e1e5b7f7f6 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -727,10 +727,10 @@ static inline void process_adjtimex_modes(const struct __kernel_timex *txc,
 	}
 
 	if (txc->modes & ADJ_MAXERROR)
-		time_maxerror = txc->maxerror;
+		time_maxerror = clamp(txc->maxerror, 0, NTP_PHASE_LIMIT);
 
 	if (txc->modes & ADJ_ESTERROR)
-		time_esterror = txc->esterror;
+		time_esterror = clamp(txc->esterror, 0, NTP_PHASE_LIMIT);
 
 	if (txc->modes & ADJ_TIMECONST) {
 		time_constant = txc->constant;