[PATCH] Pass correct length to strnlen_user in fs/exec.c

[PATCH] Pass correct length to strnlen_user in fs/exec.c

[Ryan Mallon]

Mail client was still mis-behaving. Should be fixed now.

---
Replace valid_arg_len function in fs/exec.c with max_arg_len function
and pass the correct length to strnlen_user.

Signed-off-by: Ryan Mallon <rmallon@gmail.com>
---

diff --git a/fs/exec.c b/fs/exec.c
index e19588c..12d2f7f 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -296,9 +296,9 @@ err:
 	return err;
 }
 
-static bool valid_arg_len(struct linux_binprm *bprm, long len)
+static long max_arg_len(struct linux_binprm *bprm)
 {
-	return len <= MAX_ARG_STRLEN;
+	return MAX_ARG_STRLEN;
 }
 
 #else
@@ -354,9 +354,9 @@ static int __bprm_mm_init(struct linux_binprm *bprm)
 	return 0;
 }
 
-static bool valid_arg_len(struct linux_binprm *bprm, long len)
+static long max_arg_len(struct linux_binprm *bprm)
 {
-	return len <= bprm->p;
+	return bprm->p;
 }
 
 #endif /* CONFIG_MMU */
@@ -474,18 +474,19 @@ static int copy_strings(int argc, struct user_arg_ptr argv,
 		const char __user *str;
 		int len;
 		unsigned long pos;
+		long max_len = max_arg_len(bprm);
 
 		ret = -EFAULT;
 		str = get_user_arg_ptr(argv, argc);
 		if (IS_ERR(str))
 			goto out;
 
-		len = strnlen_user(str, MAX_ARG_STRLEN);
-		if (!len || len > MAX_ARG_STRLEN)
+		len = strnlen_user(str, max_len);
+		if (!len)
 			goto out;
 
 		ret = -E2BIG;
-		if (!valid_arg_len(bprm, len))
+		if (len > max_len)
 			goto out;
 
 		/* We're going to work our way backwords. */

Re: [PATCH] Pass correct length to strnlen_user in fs/exec.c

[Andrew Morton]

On Thu, 08 Sep 2011 10:39:24 +1000
Ryan Mallon <rmallon@gmail.com> wrote:

> Replace valid_arg_len function in fs/exec.c with max_arg_len function
> and pass the correct length to strnlen_user.
> 
> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -296,9 +296,9 @@ err:
>  	return err;
>  }
>  
> -static bool valid_arg_len(struct linux_binprm *bprm, long len)
> +static long max_arg_len(struct linux_binprm *bprm)
>  {
> -	return len <= MAX_ARG_STRLEN;
> +	return MAX_ARG_STRLEN;
>  }
>  
>  #else
> @@ -354,9 +354,9 @@ static int __bprm_mm_init(struct linux_binprm *bprm)
>  	return 0;
>  }
>  
> -static bool valid_arg_len(struct linux_binprm *bprm, long len)
> +static long max_arg_len(struct linux_binprm *bprm)
>  {
> -	return len <= bprm->p;
> +	return bprm->p;
>  }
>  
>  #endif /* CONFIG_MMU */
> @@ -474,18 +474,19 @@ static int copy_strings(int argc, struct user_arg_ptr argv,
>  		const char __user *str;
>  		int len;
>  		unsigned long pos;
> +		long max_len = max_arg_len(bprm);
>  
>  		ret = -EFAULT;
>  		str = get_user_arg_ptr(argv, argc);
>  		if (IS_ERR(str))
>  			goto out;
>  
> -		len = strnlen_user(str, MAX_ARG_STRLEN);
> -		if (!len || len > MAX_ARG_STRLEN)
> +		len = strnlen_user(str, max_len);
> +		if (!len)
>  			goto out;
>  
>  		ret = -E2BIG;
> -		if (!valid_arg_len(bprm, len))
> +		if (len > max_len)
>  			goto out;
>  
>  		/* We're going to work our way backwords. */

I'm struggling to find a reason to merge this - it churns code around
rather pointlessly?

Re: [PATCH] Pass correct length to strnlen_user in fs/exec.c

[Ryan Mallon]

On 09/09/11 09:52, Andrew Morton wrote:
> On Thu, 08 Sep 2011 10:39:24 +1000
> Ryan Mallon <rmallon@gmail.com> wrote:
>
>> Replace valid_arg_len function in fs/exec.c with max_arg_len function
>> and pass the correct length to strnlen_user.
>>
>> --- a/fs/exec.c
>> +++ b/fs/exec.c
>> @@ -296,9 +296,9 @@ err:
>>  	return err;
>>  }
>>  
>> -static bool valid_arg_len(struct linux_binprm *bprm, long len)
>> +static long max_arg_len(struct linux_binprm *bprm)
>>  {
>> -	return len <= MAX_ARG_STRLEN;
>> +	return MAX_ARG_STRLEN;
>>  }
>>  
>>  #else
>> @@ -354,9 +354,9 @@ static int __bprm_mm_init(struct linux_binprm *bprm)
>>  	return 0;
>>  }
>>  
>> -static bool valid_arg_len(struct linux_binprm *bprm, long len)
>> +static long max_arg_len(struct linux_binprm *bprm)
>>  {
>> -	return len <= bprm->p;
>> +	return bprm->p;
>>  }
>>  
>>  #endif /* CONFIG_MMU */
>> @@ -474,18 +474,19 @@ static int copy_strings(int argc, struct user_arg_ptr argv,
>>  		const char __user *str;
>>  		int len;
>>  		unsigned long pos;
>> +		long max_len = max_arg_len(bprm);
>>  
>>  		ret = -EFAULT;
>>  		str = get_user_arg_ptr(argv, argc);
>>  		if (IS_ERR(str))
>>  			goto out;
>>  
>> -		len = strnlen_user(str, MAX_ARG_STRLEN);
>> -		if (!len || len > MAX_ARG_STRLEN)
>> +		len = strnlen_user(str, max_len);
>> +		if (!len)
>>  			goto out;
>>  
>>  		ret = -E2BIG;
>> -		if (!valid_arg_len(bprm, len))
>> +		if (len > max_len)
>>  			goto out;
>>  
>>  		/* We're going to work our way backwords. */
> I'm struggling to find a reason to merge this - it churns code around
> rather pointlessly?
>
That's fine. I originally went looking after a discussion with Mark
about the weird strnlen_user semantics  and this usage looked incorrect
to me because it wasn't obviously checking >= MAX_ARG_STRLEN.

The rework I think makes it a bit more clear and passes the correct max
length to strnlen_user. Its a bit odd to pass MAX_ARG_STRLEN and then
check if it is longer than bprm->len, and I guess assumes that bprm->len
is less than MAX_ARG_STRLEN.

Feel free to drop the patch if you think it is just churn.

~Ryan

Re: [PATCH] Pass correct length to strnlen_user in fs/exec.c

[halfdog]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ryan Mallon wrote:

>> ...
> That's fine. I originally went looking after a discussion with
> Mark about the weird strnlen_user semantics  and this usage looked
> incorrect to me because it wasn't obviously checking >=
> MAX_ARG_STRLEN.
> 
> The rework I think makes it a bit more clear and passes the correct
> max length to strnlen_user. Its a bit odd to pass MAX_ARG_STRLEN
> and then check if it is longer than bprm->len, and I guess assumes
> that bprm->len is less than MAX_ARG_STRLEN.
> 
> Feel free to drop the patch if you think it is just churn.

As you are already busy with fs/exec.c and strnlen_user, could you
please check, if the timerace (argv/envp corruption) using
strnlen_user could also be fixed within the same patch (if bug still
in kernel). See

https://bugzilla.kernel.org/show_bug.cgi?id=39222

The race occurs when one thread issues exec while another one with
shared memory pages is flipping char/0-bytes of the args or envptrs,
causing random split (number greater maxargs - no problem, silently
droped)/fusion (greater MAX_ARG_STRLEN - might harm dumb programs) or
removal of all args including program name on top of new stack when
calling via binfmt handlers (might have influenced old ldlinux/libc
pre 2009?? when handling suid binaries)

Kind Regards,
Roman

- -- 
http://www.halfdog.net/
PGP: 156A AE98 B91F 0114 FE88  2BD8 C459 9386 feed a bee
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFOc3tJxFmThv7tq+4RAibwAJ9CmDTlODxFuNR4KrSh9PGjgyXxQwCfeIgo
ARy24fJ6DxuKmcPNla6f0lE=
=h1TA
-----END PGP SIGNATURE-----

Re: [PATCH] Pass correct length to strnlen_user in fs/exec.c

[Ryan Mallon]

On 17/09/11 02:36, halfdog wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ryan Mallon wrote:
>
>>> ...
>> That's fine. I originally went looking after a discussion with
>> Mark about the weird strnlen_user semantics  and this usage looked
>> incorrect to me because it wasn't obviously checking >=
>> MAX_ARG_STRLEN.
>>
>> The rework I think makes it a bit more clear and passes the correct
>> max length to strnlen_user. Its a bit odd to pass MAX_ARG_STRLEN
>> and then check if it is longer than bprm->len, and I guess assumes
>> that bprm->len is less than MAX_ARG_STRLEN.
>>
>> Feel free to drop the patch if you think it is just churn.
> As you are already busy with fs/exec.c and strnlen_user, could you
> please check, if the timerace (argv/envp corruption) using
> strnlen_user could also be fixed within the same patch (if bug still
> in kernel). See
>
> https://bugzilla.kernel.org/show_bug.cgi?id=39222

With kernel.org currently being down I cannot see that bug report
unfortunately, so I don't know what the bug you are referring to is.

> The race occurs when one thread issues exec while another one with
> shared memory pages is flipping char/0-bytes of the args or envptrs,
> causing random split (number greater maxargs - no problem, silently
> droped)/fusion (greater MAX_ARG_STRLEN - might harm dumb programs) or
> removal of all args including program name on top of new stack when
> calling via binfmt handlers (might have influenced old ldlinux/libc
> pre 2009?? when handling suid binaries)

It doesn't sound like my patch would have fixed that. The only issue
that my patch would have corrected is the case where bprm->len is
greater than MAX_ARG_STRLEN. MAX_ARG_STRLEN is pretty big though (32 *
PAGE_SIZE), so I don't see that being an issue very often.

~Ryan