From: Andrew Morton <akpm@linux-foundation.org>
To: Shakesh Jain <shjain@akamai.com>, ShakeshJain@akamai.com
Cc: linux-kernel@vger.kernel.org, juhlenko@akamai.com,
Alexey Dobriyan <adobriyan@gmail.com>,
"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [PATCH] sysctl: min-max range check is broken
Date: Thu, 5 Feb 2009 12:29:41 -0800 [thread overview]
Message-ID: <20090205122941.17805ff1.akpm@linux-foundation.org> (raw)
In-Reply-To: <20090204084022.GB14071@akamai.com>
On Wed, 4 Feb 2009 00:40:22 -0800
Shakesh Jain <shjain@akamai.com>, ShakeshJain@akamai.com wrote:
> do_proc_dointvec_minmax_conv() which gets callled from
> proc_dointvec_minmax proc_handler doesn't increment the pointer to
> the 'min' (extra1) and 'max' (extra2) after each range check which
> results in doing the check against same set of min and max values.
>
> This breaks the range checking for those sysctl's where you can
> write multiple values to /proc with each variable having its own range
> specification.
>
> It seems to be implemented for the sysctl() system call strategy in
> sysctl_intvec() where min and max are treated as arrays.
>
> Signed-off-by: Shakesh Jain <shjain@akamai.com>
> ---
> kernel/sysctl.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> ========================================================================
> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> index 368d163..50bffcd 100644
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -2377,8 +2377,8 @@ static int do_proc_dointvec_minmax_conv(int *negp, unsigned long *lvalp,
> struct do_proc_dointvec_minmax_conv_param *param = data;
> if (write) {
> int val = *negp ? -*lvalp : *lvalp;
> - if ((param->min && *param->min > val) ||
> - (param->max && *param->max < val))
> + if ((param->min && *(param->min++) > val) ||
> + (param->max && *(param->max++) < val))
> return -EINVAL;
> *valp = val;
> } else {
Scary code.
It will unconditionally increment param->min.
But it will only increment param->max if the (*param->min > val) test
succeeded.
Is this really the intended and correct behaviour? It seems odd.
Even if it _is_ correct, can the code be rearranged to be less scary?
next prev parent reply other threads:[~2009-02-05 20:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-04 8:40 [PATCH] sysctl: min-max range check is broken Shakesh Jain, ShakeshJain
2009-02-05 20:29 ` Andrew Morton [this message]
2009-02-05 20:55 ` Eric W. Biederman
2009-02-05 21:19 ` Alexey Dobriyan
2009-02-05 21:40 ` Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090205122941.17805ff1.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=ShakeshJain@akamai.com \
--cc=adobriyan@gmail.com \
--cc=ebiederm@xmission.com \
--cc=juhlenko@akamai.com \
--cc=linux-kernel@vger.kernel.org \
--cc=shjain@akamai.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.