From: ebiederm@xmission.com (Eric W. Biederman)
To: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Shakesh Jain <shjain@akamai.com>,
ShakeshJain@akamai.com, linux-kernel@vger.kernel.org,
juhlenko@akamai.com
Subject: Re: [PATCH] sysctl: min-max range check is broken
Date: Thu, 05 Feb 2009 13:40:05 -0800 [thread overview]
Message-ID: <m1fxissgui.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <20090205211933.GA13312@x200.localdomain> (Alexey Dobriyan's message of "Fri\, 6 Feb 2009 00\:19\:34 +0300")
Alexey Dobriyan <adobriyan@gmail.com> writes:
>> 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.
>
> Multiple values, each one is bounded by it's own set of values.
Nack. That is a change to the users of sysctl. An array
of minmax values appears to be a brand new extension therefore
we should not make this change.
If we want new behavior we should introduce new helpers.
>> For the original sysctl design it may have made
>> some sense. New code should be one value per file.
>
> So leave them alone.
Sure. My point is that we don't care about this for new code.
Old code was tested and used with the proc version.
NO ONE uses sys_sysctl NO ONE.
>> --- 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;
>
> Correct way is:
>
> min[i] <= val[i] <= max[i]
>
> This is what sysctl_intvec() does.
Therefore sysctl_intvec is wrong because it does not match
proc_dointvec_minmax. proc_dointvec_minmax is definitive as that what
people use and test. sysctl_intvec is a vestigial appendage that
was never really used, and it is already deprecated and scheduled for
remove because of this.
The only way to support the case of arrays of minmax values is to
show code that cares. I did not see anyone passing in an array
in .extra one. So you are advocating code that will walk around
and read random values from the kernels .data section. Which
is VERY broken.
Eric
prev parent reply other threads:[~2009-02-05 21:40 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
2009-02-05 20:55 ` Eric W. Biederman
2009-02-05 21:19 ` Alexey Dobriyan
2009-02-05 21:40 ` Eric W. Biederman [this message]
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=m1fxissgui.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