Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp7153223ybi; Mon, 8 Jul 2019 15:43:28 -0700 (PDT) X-Google-Smtp-Source: APXvYqzE56mqU+P6ph+65wX4LYBkqmr8F4RQ10IKccnoUZjUuf7vvCqhvwNVtbVgvSDSx+R8YFge X-Received: by 2002:a17:902:1e6:: with SMTP id b93mr27608652plb.295.1562625808808; Mon, 08 Jul 2019 15:43:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562625808; cv=none; d=google.com; s=arc-20160816; b=e3extBOINYJm6ywAjybZ52QquVxUUObqdHVLg2Ik1pFVBQdoPgM2SxD7rsEN7Q/v+e x+5E5hoBbNUoKBI6NBWjhXA4EqbxdgdOqvmBaE+4pVPfoCVTR6KZ1R8kLK3ufk303dK1 jl6U9Hz0IDEQVf3Ga4+9Uc08ri6oXkvNDRxfPtSRAoOiMCzkhcyUXOq7aH9YGabyWNh2 rizqmuTTXfsOTOk/2iEW0Lqd5mS75hhEoeSmaG95bzxCh/mipCN0+v8WW9u7Ppvzq0ue m6ct7weE+jYyZjS1b4fPpCnRGOiO/Fz6D7MjuEkkMaB5m40O9Pbb9u9/AHVN6Rhkrcfm 3Xow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=HANEys3LwMMarvQrMRgIUfN0qDIaxMbeh5Zb+J/99Zg=; b=KYp3cItvtfMYlhriggOW0FZn38Sa4pA5x6x1rEP79A1OzTl6G4KeX5ueTDWTN8az5S SrsFoNxQ4EgzBDGZ1RqjpuC0D1AcQvc4gvajUIkK1y5Iy/b/nMDcEWG28wT9LIWGv0ot eyyi6jEf/3xCrQrS7944HPH/6Fsnw4BimC/P+SM0Er2yExqetUksfkHEzfPj1iEHk8IA bSy0Hfd5WPhrjut5fBfty68+nKm1oa5Ker0U5e2cCs9IcBJ4iUvGsRU7K8KezuerFehw IBjao9iwX5RtUTfpwvBzWiMcGVpIGiFNANpyLPcBUKT573dVTfAzvIuJqOi+EDPpykoO kbrw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=VIsVRnmG; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i5si675523pjk.57.2019.07.08.15.43.14; Mon, 08 Jul 2019 15:43:28 -0700 (PDT) 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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=VIsVRnmG; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730332AbfGHQjE (ORCPT + 99 others); Mon, 8 Jul 2019 12:39:04 -0400 Received: from mail-pl1-f195.google.com ([209.85.214.195]:33524 "EHLO mail-pl1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725836AbfGHQjE (ORCPT ); Mon, 8 Jul 2019 12:39:04 -0400 Received: by mail-pl1-f195.google.com with SMTP id c14so8547101plo.0 for ; Mon, 08 Jul 2019 09:39:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=HANEys3LwMMarvQrMRgIUfN0qDIaxMbeh5Zb+J/99Zg=; b=VIsVRnmGojer3AbNkAsEx36TTWcdbcz6fKFtvDsuT3/i99lJq5zpV4awq3pZRIjdbb tArfVrO98RZEn2/OO68iwAdDwnc9PN7km3mg9d+cYHbk0KUmhhoZgfr/PqVd/KBpEs+x JHUd16JMhS7QCF4dQjc3caD6anztPkYFK9mf0vs7DNJBO9EH8E8q6shaLnTIFtZPDljO iHdizd1lHAVv8oJlLvdpL8PhN51v+GYMro8gM2Ax/jAbg/0uAauDtyFKFq/D5tpjN+r1 EMjRdElWcbc9pf+6ewrjGty08MNVW5cVFe+JaLqdoeE8HZxJrhI80i3w54z1FXWhNWb6 Gzug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=HANEys3LwMMarvQrMRgIUfN0qDIaxMbeh5Zb+J/99Zg=; b=RRDCl/05P/P/OqodkBVf77FFkCYexk1C/pRCrh+HD6NfW68vW/NpiN/EcBlgJtOqZx tG5azuuZ5knPkljExbh8IkEvhOdGhR0D5U8KSAq/J1wTTclmPkVS1J+6trjFggUrhLSl 1VU+BVnYKM03EmMOaiPQqrvoC0fP6b+8YkbhV0Zgn6khv947eTcS48EwRS9cwTW0jXve DR+KdSYK1kWYi6i9KykTt2DrffYoWSa9KoVohubPFQd+cYnmAA15asyo500s+JYTii3L c9mFLJoLydzwFMzKIAA+RxSSHO7vOGcbL8P/cXtsvWX4wD71I8p5dVcfKLdHklrCALxL vcVQ== X-Gm-Message-State: APjAAAUCbxWOQVLc+XWYVrrS1PqnHStknMi/IK+epwslQ139k5Dk59s3 VcdhT7U/sYukPyO2TW/iR7A= X-Received: by 2002:a17:902:d715:: with SMTP id w21mr27081665ply.261.1562603943955; Mon, 08 Jul 2019 09:39:03 -0700 (PDT) Received: from localhost (c-73-222-71-142.hsd1.ca.comcast.net. [73.222.71.142]) by smtp.gmail.com with ESMTPSA id d2sm17639026pgo.0.2019.07.08.09.39.02 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 08 Jul 2019 09:39:03 -0700 (PDT) Date: Mon, 8 Jul 2019 09:39:00 -0700 From: Richard Cochran To: ZhangXiaoxu Cc: john.stultz@linaro.org, tglx@linutronix.de, sboyd@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] time: Validate the usec before covert to nsec in do_adjtimex Message-ID: <20190708163900.yhzb2qh7w5mlcqkc@localhost> References: <1562572504-142115-1-git-send-email-zhangxiaoxu5@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1562572504-142115-1-git-send-email-zhangxiaoxu5@huawei.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 08, 2019 at 03:55:04PM +0800, ZhangXiaoxu wrote: > When covert the usec to nsec, it will multiple 1000, it maybe > overflow and lead an undefined behavior. > > For example, users may input an negative tv_usec values when > call adjtimex syscall, then multiple 1000 maybe overflow it > to a positive and legal number. > > So, we should validate the usec before coverted it to nsec. > > Signed-off-by: ZhangXiaoxu > --- > kernel/time/timekeeping.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c > index 44b726b..e5c1d00 100644 > --- a/kernel/time/timekeeping.c > +++ b/kernel/time/timekeeping.c > @@ -1272,9 +1272,6 @@ static int timekeeping_inject_offset(const struct timespec64 *ts) > struct timespec64 tmp; > int ret = 0; > > - if (ts->tv_nsec < 0 || ts->tv_nsec >= NSEC_PER_SEC) > - return -EINVAL; > - > raw_spin_lock_irqsave(&timekeeper_lock, flags); > write_seqcount_begin(&tk_core.seq); > > @@ -2321,6 +2318,9 @@ int do_adjtimex(struct __kernel_timex *txc) > > if (txc->modes & ADJ_SETOFFSET) { > struct timespec64 delta; > + > + if (txc->time.tv_usec < 0 || txc->time.tv_usec >= USEC_PER_SEC) > + return -EINVAL; This test is wrong. If the tv_usec field is in nanoseconds, then the value can easily be greater than USEC_PER_SEC. > delta.tv_sec = txc->time.tv_sec; > delta.tv_nsec = txc->time.tv_usec; > if (!(txc->modes & ADJ_NANO)) > -- > 2.7.4 > Thanks, Richard