[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180312205920.GD4449@wotan.suse.de>
Date: Mon, 12 Mar 2018 20:59:20 +0000
From: "Luis R. Rodriguez" <mcgrof@...nel.org>
To: Waiman Long <longman@...hat.com>
Cc: "Luis R. Rodriguez" <mcgrof@...nel.org>,
Kees Cook <keescook@...omium.org>,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Al Viro <viro@...iv.linux.org.uk>,
Matthew Wilcox <willy@...radead.org>
Subject: Re: [PATCH v4 2/6] proc/sysctl: Check for invalid flags bits
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 <longman@...hat.com>
> >> ---
> >> 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
Powered by blists - more mailing lists