Received: by 10.213.65.68 with SMTP id h4csp290453imn; Mon, 12 Mar 2018 14:00:44 -0700 (PDT) X-Google-Smtp-Source: AG47ELsia+EjzICi0deiYZfcYymFI6P2S9acejUqus8fNrw2l/OQ1k62FGKI+fCS08rVHokbtxJ1 X-Received: by 10.99.123.80 with SMTP id k16mr5168110pgn.173.1520888444306; Mon, 12 Mar 2018 14:00:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1520888444; cv=none; d=google.com; s=arc-20160816; b=ooY5yI5kmpVo+9xLEmiLsDPUrpCgiLxWU3lbelnjCtafVlCpxG6DRVHFC7ojtu/5GB CjgqNKYEiTLIAfXhoZOAm+03I+61EATSni0AfBJdUXp/ScySTLpJQGcW59oBtOV+TjIv 0SL5gM/3r09CHwiRYsYNzyPQHNVjjGl4DAOaham1rW3cb9b+M6Q6lhkL01w/cjO8vtSP eH6qpfflu+9RvzsGDhoTw1S7IGkFCm3eBQS4adnw7NyaVs1dZQSMoO402Db7tD4BCuaA bHxXDQMV7Pzd4D2ZhKsTpZZFnsSGMpTcYlZrNMwiGZla+VIbygNounJYrYnmm0TmYQYO LkJg== 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:arc-authentication-results; bh=M5OX1HJgvAXJutxD41XiePRVNn8njjhPClpV82tYz+8=; b=0d88t8UQyE4W4xXTRMN6g11A14jCsbuICerJUnugN/MDReOE1csO+VjeO1S5kfn6PG cxB/MJzoek975pGmTWN3aYknaQHSs7wDO8rF9Q/Ki1IPgzfCoFzPWtWLzqlmM5KdwOFf 7FEhRFnFzRXzZRs5wWh/1n+c4luvKXzNMYhWoNc82f/PFFDkaMyiDFXYUGrEnxLfrBW0 H5O0AcvWudmenU1GJvLXbtcSwmjKnEfx81/JsD/jRNa5fghZ0lysGSN0GQZUdIco9xmz PfftN7IYkZoA0zA/tCUkLGB5jejjvtTwVNYyd8telowR/zTC6xcnMmNSCYn81kiTh72a HI3w== 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 s6si5498747pgp.577.2018.03.12.14.00.22; Mon, 12 Mar 2018 14:00:44 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932439AbeCLU7X (ORCPT + 99 others); Mon, 12 Mar 2018 16:59:23 -0400 Received: from mx2.suse.de ([195.135.220.15]:48620 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932302AbeCLU7W (ORCPT ); Mon, 12 Mar 2018 16:59:22 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id E4932AEF7; Mon, 12 Mar 2018 20:59:20 +0000 (UTC) Date: Mon, 12 Mar 2018 20:59:20 +0000 From: "Luis R. Rodriguez" To: Waiman Long Cc: "Luis R. Rodriguez" , Kees Cook , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Andrew Morton , Al Viro , Matthew Wilcox Subject: Re: [PATCH v4 2/6] proc/sysctl: Check for invalid flags bits Message-ID: <20180312205920.GD4449@wotan.suse.de> References: <1520885744-1546-1-git-send-email-longman@redhat.com> <1520885744-1546-3-git-send-email-longman@redhat.com> <20180312204614.GZ4449@wotan.suse.de> <2621ea58-174f-bfe9-8c34-12501bb775fa@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2621ea58-174f-bfe9-8c34-12501bb775fa@redhat.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 12, 2018 at 04:54:51PM -0400, Waiman Long wrote: > On 03/12/2018 04:46 PM, Luis R. Rodriguez wrote: > > On Mon, Mar 12, 2018 at 04:15:40PM -0400, Waiman Long wrote: > >> Checking code is added to check for invalid flags in the ctl_table > >> and return error if an unknown flag is used. > > This should be merged with the first patch otherwise there are atomic > > points in time on the commit log history where invalid values are allowed > > and that makes no sense. > > > > This can probably be expanded to verify semantics further. Details > > below. > >> Signed-off-by: Waiman Long > >> --- > >> fs/proc/proc_sysctl.c | 12 ++++++++++++ > >> 1 file changed, 12 insertions(+) > >> > >> diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c > >> index 493c975..67c0c82 100644 > >> --- a/fs/proc/proc_sysctl.c > >> +++ b/fs/proc/proc_sysctl.c > >> @@ -1092,6 +1092,16 @@ static int sysctl_check_table_array(const char *path, struct ctl_table *table) > >> return err; > >> } > >> > >> +static int sysctl_check_flags(const char *path, struct ctl_table *table) > >> +{ > >> + int err = 0; > >> + > >> + if (table->flags & ~CTL_TABLE_FLAGS_ALL) > >> + err = sysctl_err(path, table, "invalid flags"); > > What if a range for the upper limit is set but not the lower limit and > > the user goes over the lower limit? > > > > How about the inverse? > > > > Do we need both ranges set? > > > > Luis > > This check is just to make sure that no invalid flag bit is set. Range > clamping is just one of flag bits, though this is the only one currently > supported. In fact, it is allowed that the minimum or maximum can be > left unspecified. In this case, no minimum or maximum checking will be > done. So I don't see anything related to range checking should be put here. What if minimum is greater than maximum? Luis