[PATCH] sysctl: fix improper indication of integer sysctl parameter

[PATCH] sysctl: fix improper indication of integer sysctl parameter

[Mitsuo Hayasaka]

Hi,

This patch fixes the improper type casting of integer
sysctl parameters.

When we read the sysctl parameter, they are always treated
as signed integer, and are casted into unsigned long type
in the current kernel. If we set a value equivalent to
(the maximum value in signed integer + 1) which is a power
of 2 and just causes the overflow, they outputs unexpected
value.

This bug can be reproduced as follows.

Example)
 # echo $((1<<31)) > /proc/sys/fs/lease-break-time
 # cat /proc/sys/fs/lease-break-time
 -18446744071562067968
   (It should be -2147483648.)
or
 # echo XXX > /proc/sys/fs/pipe-max-size
   (where XXX is an arbitrary number between (1<<30 + 1) and
    (1<<31 - 1) since the pipe-max-size is rounded up to a
    power of 2 in kernel.)
 # cat /proc/sys/fs/pipe-max-size
 -18446744071562067968
   (It should be -2147483648.)

To fix this problem, this patch casts the negative integer
into unsigned int type, instead of unsigned long type.

Signed-off-by: Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: David Howells <dhowells@redhat.com>
Cc: James Morris <james.l.morris@oracle.com>
---

 kernel/sysctl.c |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 97186b9..e282b5b 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1789,7 +1789,7 @@ static int do_proc_dointvec_conv(bool *negp, unsigned long *lvalp,
 		int val = *valp;
 		if (val < 0) {
 			*negp = true;
-			*lvalp = (unsigned long)-val;
+			*lvalp = (unsigned int)-val;
 		} else {
 			*negp = false;
 			*lvalp = (unsigned long)val;
@@ -1982,7 +1982,7 @@ static int do_proc_dointvec_minmax_conv(bool *negp, unsigned long *lvalp,
 		int val = *valp;
 		if (val < 0) {
 			*negp = true;
-			*lvalp = (unsigned long)-val;
+			*lvalp = (unsigned int)-val;
 		} else {
 			*negp = false;
 			*lvalp = (unsigned long)val;
@@ -2197,7 +2197,7 @@ static int do_proc_dointvec_jiffies_conv(bool *negp, unsigned long *lvalp,
 		unsigned long lval;
 		if (val < 0) {
 			*negp = true;
-			lval = (unsigned long)-val;
+			lval = (unsigned int)-val;
 		} else {
 			*negp = false;
 			lval = (unsigned long)val;
@@ -2220,7 +2220,7 @@ static int do_proc_dointvec_userhz_jiffies_conv(bool *negp, unsigned long *lvalp
 		unsigned long lval;
 		if (val < 0) {
 			*negp = true;
-			lval = (unsigned long)-val;
+			lval = (unsigned int)-val;
 		} else {
 			*negp = false;
 			lval = (unsigned long)val;
@@ -2241,7 +2241,7 @@ static int do_proc_dointvec_ms_jiffies_conv(bool *negp, unsigned long *lvalp,
 		unsigned long lval;
 		if (val < 0) {
 			*negp = true;
-			lval = (unsigned long)-val;
+			lval = (unsigned int)-val;
 		} else {
 			*negp = false;
 			lval = (unsigned long)val;

Re: [PATCH] sysctl: fix improper indication of integer sysctl parameter

[David Howells]

Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com> wrote:

> When we read the sysctl parameter, they are always treated
> as signed integer, and are casted into unsigned long type
> in the current kernel. If we set a value equivalent to
> (the maximum value in signed integer + 1)

Wouldn't it be better to return EINVAL or EDOM?

David

Re: [PATCH] sysctl: fix improper indication of integer sysctl parameter

[Eric W. Biederman]

David Howells <dhowells@redhat.com> writes:

> Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com> wrote:
>
>> When we read the sysctl parameter, they are always treated
>> as signed integer, and are casted into unsigned long type
>> in the current kernel. If we set a value equivalent to
>> (the maximum value in signed integer + 1)
>
> Wouldn't it be better to return EINVAL or EDOM?

Yes we should definitely fail the write in the case where we write an
unsigned value and we can not fit that value in an integer.

There will still remain the bug of reading the integer
where (-val == val) && val < 0.  In that case we do want to an
(unsigned int) before storing it in an unsinged long.

The decription of the patch is confusing.

The problem is not the cast to unsigned long, the problem is
the implicit cast to signed long which happens before the cast
to unsigned long.  I think this is a case where C's casting rules
get it wrong.  If I have an explicit cast why add an implicit
cast to do sign extension.  Sigh.

Mitsuo since you are looking at this do you think you could fix the
write side of the problem as well, and check to make cetain the
unsigned value we write will fit in an interger.

Eric