]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
Fixes for 4.19
authorSasha Levin <sashal@kernel.org>
Mon, 12 Aug 2024 10:01:54 +0000 (06:01 -0400)
committerSasha Levin <sashal@kernel.org>
Mon, 12 Aug 2024 10:01:54 +0000 (06:01 -0400)
Signed-off-by: Sasha Levin <sashal@kernel.org>
queue-4.19/ntp-clamp-maxerror-and-esterror-to-operating-range.patch [new file with mode: 0644]
queue-4.19/series

diff --git a/queue-4.19/ntp-clamp-maxerror-and-esterror-to-operating-range.patch b/queue-4.19/ntp-clamp-maxerror-and-esterror-to-operating-range.patch
new file mode 100644 (file)
index 0000000..90a5b8e
--- /dev/null
@@ -0,0 +1,74 @@
+From 430345cf6107334938107ba507d3a351e97193f1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 17 May 2024 20:22:44 +0000
+Subject: ntp: Clamp maxerror and esterror to operating range
+
+From: Justin Stitt <justinstitt@google.com>
+
+[ 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@google.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: Miroslav Lichvar <mlichvar@redhat.com>
+Link: https://lore.kernel.org/all/20240517-b4-sio-ntp-usec-v2-1-d539180f2b79@google.com
+Closes: https://github.com/KSPP/linux/issues/354
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/time/ntp.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
+index e1110a7bd3e64..a082403a079ea 100644
+--- a/kernel/time/ntp.c
++++ b/kernel/time/ntp.c
+@@ -686,10 +686,10 @@ static inline void process_adjtimex_modes(const struct timex *txc, s32 *time_tai
+       }
+       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;
+-- 
+2.43.0
+
index abffe6dfe2093d0d7bb22dc58f98dbf728a4935e..2399178230464d4a60cda0dfd49688d5af32e67e 100644 (file)
@@ -175,3 +175,4 @@ usb-serial-debug-do-not-echo-input-by-default.patch
 usb-gadget-core-check-for-unset-descriptor.patch
 scsi-ufs-core-fix-hba-last_dme_cmd_tstamp-timestamp-updating-logic.patch
 tick-broadcast-move-per-cpu-pointer-access-into-the-atomic-section.patch
+ntp-clamp-maxerror-and-esterror-to-operating-range.patch