Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1930094yba; Mon, 15 Apr 2019 01:05:13 -0700 (PDT) X-Google-Smtp-Source: APXvYqyv9gsxqEwmo3dmYnFMnlU2GM08r2ymsgj7bSef0ga9VGJERDLTM5xvLHHYYImsbaN0xwAF X-Received: by 2002:a62:41dc:: with SMTP id g89mr74145481pfd.109.1555315513402; Mon, 15 Apr 2019 01:05:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555315513; cv=none; d=google.com; s=arc-20160816; b=bqfuJPQ7VlFbv3oAeMnuO2LkUDqAI2uuTyo4V/3TxTnNxMiCDYIngFmZuaKBpOBPku X50vhGB0HImeceZ+sGvpdVRPcskU7502Bz+/DIJi/pMGjSoIyb8MFyywk+xHKIbQeDAc 5iCeNwNEVCbzASAkVPRtrYUi/DcSS2luq31BkYCEKQnHE9AX52W/Y11sLgdzJnaSel12 efed9B2A15hCNXaTtV6x9T1VrSvHpemoN5gldVisUpJWt/shDaYdkYXxUaWUU3W7CtYL 9xr74RTeyh4hCi2XPBJbFTjAIWwl8a+WpafJrlEMTtMoKvf6TF2s0BGihYHDRedylB29 w8Fw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=933JfDMO/1tW7WuUydACw3VvF6ahaiXpe8YkBr+QZgk=; b=uLP+oXfqzxqCd45VBz4olVAyFnwMOTIPN53bvLWsZjkVZYI5VQ9/UPv9SA3/feY6dj sEhaDsUP3Eow5+TE/z/u4Nub4Gx72AFaYC6ZYZmqJNMWdRgMLrpKJJ1Hg3APen6JEeGN azEVAx53wDhu7azcFnt2BNLnkFa/qsIKEC0iXMBYeHWKcoV2og2qov0pNac/ziHOREcU VBY8peVFqLGKhoRe8iHANiG6YSxQ7Jv4o+pPZredjYm4D8BQgEXdn15x5zuXn1GYZ5kH as0wzzNZTfHC0Zi+2UOEKNx8/0sRZqJQmxUKvc9FoaSnAu0QhYIN8nHN4HsoVpfjaAEL yCoA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 36si45200663pgn.272.2019.04.15.01.04.56; Mon, 15 Apr 2019 01:05:13 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726227AbfDOIDG (ORCPT + 99 others); Mon, 15 Apr 2019 04:03:06 -0400 Received: from mail-ot1-f48.google.com ([209.85.210.48]:43365 "EHLO mail-ot1-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725794AbfDOIDG (ORCPT ); Mon, 15 Apr 2019 04:03:06 -0400 Received: by mail-ot1-f48.google.com with SMTP id u15so13623071otq.10 for ; Mon, 15 Apr 2019 01:03:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=933JfDMO/1tW7WuUydACw3VvF6ahaiXpe8YkBr+QZgk=; b=jhx6zW1S0xrkuBPVNbqGMqmcOCVcdG9ypYiSO31uCCHhAy0VnKjC/d0VhaChhK3uF0 FD5zOqBPF3E92LcCMdZYcv8LG48ips8UapDqMvZuiokFXlMSY37T5+Rcep249Z/Gq1yh oOYxfvwWsQ64ZxT6uRThun+0mUCganDMyYA2somym6W0yamPkUb/fTMkasc892xVyIsc PgFwEERoFP4flZ+0XxiZoti+6v4+Dk4BXw51saWNh/qnLYMTsEcRViSbYuHUiRUHxXco 1a3Flutt4pNPV871I0fmlGfBdgZRA84U9IZUcI6UUgcfEZ4apkpSHLiahIPYJGC6+MQG mocg== X-Gm-Message-State: APjAAAW8XmgZ4xpmd81zw/IpEhrkeo/aMLJi94hjRf5x90xl3L2zCcda K4iKhRpj6+HqiIc+X0s5erUhRfJZVJHldpAflMeVuA== X-Received: by 2002:a9d:27e9:: with SMTP id c96mr46997116otb.206.1555315385036; Mon, 15 Apr 2019 01:03:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ondrej Mosnacek Date: Mon, 15 Apr 2019 10:02:54 +0200 Message-ID: Subject: Re: kernel/time/ntp.c: Possible off-by-one error in TAI range check? To: Roman Zippel Cc: Thomas Gleixner , John Stultz , Stephen Boyd , Andrew Morton , Linux kernel mailing list Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 8, 2019 at 10:47 AM Ondrej Mosnacek wrote: > Hello, > > while writing tests for clock adjustment auditing [1] [2], I stumbled > upon a strange behavior of adjtimex(2) when setting the TAI offset... > > Commit 153b5d054ac2 ("ntp: support for TAI") added a possibility to > change the TAI offset from userspace via adjtimex(2). The code checks > if the input value (txc->constant) is greater than 0 and if it is not, > then it doesn't modify the value. Ignoring the fact that this check > should probably be in timekeeping_validate_timex() and cause -EINVAL > to be returned when false, I find it strange that the check doesn't > allow to set the value to 0, which seems to be the default value... > > Was this behavior intended or should the code actually check for > txc->constant >= 0 instead of txc->constant > 0? Ping? > > Thanks, > > [1] https://github.com/linux-audit/audit-kernel/issues/10 > [2] https://github.com/linux-audit/audit-kernel/wiki/RFE-More-detailed-auditing-of-changes-to-system-clock > > -- > Ondrej Mosnacek > Software Engineer, Security Technologies > Red Hat, Inc. -- Ondrej Mosnacek Software Engineer, Security Technologies Red Hat, Inc.