Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp3231408ybc; Thu, 14 Nov 2019 06:07:03 -0800 (PST) X-Google-Smtp-Source: APXvYqxxQk02whVBOpQLCxmYTOszoZyhcJ4ErU50ALJq+OYF8IpIhPsjcDkpm4ejj6niKti+XId2 X-Received: by 2002:a17:906:5586:: with SMTP id y6mr8519462ejp.76.1573740422927; Thu, 14 Nov 2019 06:07:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573740422; cv=none; d=google.com; s=arc-20160816; b=TgqPM1j184agxT8cDr6EZb1h4z+7JHlyM9WRM9XLnDbuAXxZOOu6uu4gXJJBwlSeaE vwLyM2a+xGObD4c4zSbmJgDVHc1iFa4hkdWsBFHTb5zvrKskk6FKYpqd28tu65pfA/QH S0xfhSTQFuwzHZJIh+foiusMfuRhBgV9aHt2X4wJyfhq56tUoUM5QOR2k1+4FIPF/ZzM j3SDhwW+uba0SnYalYulZm1KS/bzeDPr3HhYA8S0ZRoydxGbNSRquGQYIYdIok5s/CNS +2WQreCE8SAZKbdlP0qBZ/GpmEmaLTGftATJpBOPCb0IIcHbCxhJKL0eWqa0PFbpy5uz EjWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=XlcWG/dVdzT0kipsSMOUseeBj6exP+cX/X0hXdcQHms=; b=qWCvrYLZH7EOJtKkRhQkL8npD+8Dj/gc7cVeM9Yc352ler810KbMdVeucDOGDaGWyv pcoEeBTc6rdeRDN/YYUdaeNqibzRvX2kJUh9EPZG35Wy7wF5bG23sP+lg1GJtCTMrAFr P6gTXa2ByYcFq4Mssp8ZrPaHqCn3KaQHxUyDixanD7JK41QlBC3ya7XW26rq8BfV5RPG 3jUmJmI1gVRaGT1v/xvPBS6Q09vhEOtR7atmLGFxxrWd2kzCWsmyJXZYRMRe19Fte7/6 C5Yc+5q3D71QPV8y+jjpQAdcVhLMIrC1aeLP8g2x2/KQ4FGTI77UzVPwfc8I8wwgN3Be rsuQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 92si4595941edh.321.2019.11.14.06.06.34; Thu, 14 Nov 2019 06:07:02 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727121AbfKNOFP (ORCPT + 99 others); Thu, 14 Nov 2019 09:05:15 -0500 Received: from Galois.linutronix.de ([193.142.43.55]:40734 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726327AbfKNOFO (ORCPT ); Thu, 14 Nov 2019 09:05:14 -0500 Received: from [5.158.153.52] (helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iVFjv-0003mN-UV; Thu, 14 Nov 2019 15:04:52 +0100 Date: Thu, 14 Nov 2019 15:04:51 +0100 (CET) From: Thomas Gleixner To: Arnd Bergmann cc: y2038 Mailman List , John Stultz , "linux-kernel@vger.kernel.org" , Stephen Boyd , David Howells , Al Viro , Deepa Dinamani , Christian Brauner , Jens Axboe , Ingo Molnar , Corey Minyard , zhengbin , Li RongQing , Linux API Subject: Re: [PATCH 17/23] y2038: time: avoid timespec usage in settimeofday() In-Reply-To: Message-ID: References: <20191108210236.1296047-1-arnd@arndb.de> <20191108211323.1806194-8-arnd@arndb.de> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 14 Nov 2019, Arnd Bergmann wrote: > On Wed, Nov 13, 2019 at 10:53 PM Thomas Gleixner wrote: > > > > On Fri, 8 Nov 2019, Arnd Bergmann wrote: > > > -SYSCALL_DEFINE2(settimeofday, struct timeval __user *, tv, > > > +SYSCALL_DEFINE2(settimeofday, struct __kernel_old_timeval __user *, tv, > > > struct timezone __user *, tz) > > > { > > > struct timespec64 new_ts; > > > - struct timeval user_tv; > > > struct timezone new_tz; > > > > > > if (tv) { > > > - if (copy_from_user(&user_tv, tv, sizeof(*tv))) > > > + if (get_user(new_ts.tv_sec, &tv->tv_sec) || > > > + get_user(new_ts.tv_nsec, &tv->tv_usec)) > > > return -EFAULT; > > > > How is that supposed to be correct on a 32bit kernel? > > I don't see the problem you are referring to. This should behave the > same way on a 32-bit kernel and on a 64-bit kernel, sign-extending > the tv_sec field, and copying the user tv_usec field into the > kernel tv_nsec, to be multiplied by 1000 a few lines later. You're right. Tired brain failed to see the implicit sign extension in get_user(). > Am I missing something? No. > > > - if (!timeval_valid(&user_tv)) > > > + if (tv->tv_usec > USEC_PER_SEC) > > > return -EINVAL; > > > > That's incomplete: > > > > static inline bool timeval_valid(const struct timeval *tv) > > { > > /* Dates before 1970 are bogus */ > > if (tv->tv_sec < 0) > > return false; > > > > /* Can't have more microseconds then a second */ > > if (tv->tv_usec < 0 || tv->tv_usec >= USEC_PER_SEC) > > return false; > > > > return true; > > } > > My idea was to not duplicate the range check that is done > in do_sys_settimeofday64() and again in do_settimeofday64: > > if (!timespec64_valid_settod(ts)) > return -EINVAL; > > The only check we should need in addition to this is to ensure > that passing an invalid tv_usec number doesn't become an > unexpectedly valid tv_nsec after the multiplication. Right, but please add a proper comment as you/we are going to scratch heads 4 weeks from now when staring at that check and wondering why it is incomplete. Thanks, tglx