From: ebiederm@xmission.com (Eric W. Biederman)
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Shakesh Jain <shjain@akamai.com>,
ShakeshJain@akamai.com, linux-kernel@vger.kernel.org,
juhlenko@akamai.com, Alexey Dobriyan <adobriyan@gmail.com>
Subject: Re: [PATCH] sysctl: min-max range check is broken
Date: Thu, 05 Feb 2009 12:55:56 -0800 [thread overview]
Message-ID: <m1zlh0txgj.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <20090205122941.17805ff1.akpm@linux-foundation.org> (Andrew Morton's message of "Thu\, 5 Feb 2009 12\:29\:41 -0800")
Andrew Morton <akpm@linux-foundation.org> writes:
> 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.
I just did a quick grep for .extra1 and I don't see anywhere we use
the code as described.
>> It seems to be implemented for the sysctl() system call strategy in
>> sysctl_intvec() where min and max are treated as arrays.
Yep. There is an inconsistency here. Given how sysctl is used and
tested, and the fact I could not find where it appears that anyone is
passing an array into min/max I would say that the proc version is
correct and the sysctl version is wrong.
The untested patch below looks like it will fix the this.
I don't know if there are any cases where we use minmax with an array
of integers but I don't see the point of using an array of minmax
values at this point. For the original sysctl design it may have made
some sense. New code should be one value per file.
Eric
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 790f9d7..4050ce1 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -2916,9 +2916,9 @@ int sysctl_intvec(struct ctl_table *table,
int value;
if (get_user(value, vec + i))
return -EFAULT;
- if (min && value < min[i])
+ if (min && value < *min)
return -EINVAL;
- if (max && value > max[i])
+ if (max && value > *max)
return -EINVAL;
}
}
next prev parent reply other threads:[~2009-02-05 20:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-04 8:40 Shakesh Jain, ShakeshJain
2009-02-05 20:29 ` Andrew Morton
2009-02-05 20:55 ` Eric W. Biederman [this message]
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=m1zlh0txgj.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=ShakeshJain@akamai.com \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome