[PATCH] Check return from argv_split() in do_coredump().

[PATCH] Check return from argv_split() in do_coredump().

[Tetsuo Handa]

do_coredump() accesses helper_argv[0] without checking helper_argv != NULL.
Though, likely helper_argv != NULL.

Below versions have this problem.

  2.6.24.7
  2.6.25.20
  2.6.26.8
  2.6.27.10
  2.6.28-rc9
  mmotm 2008-12-22-16-14

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
---
 fs/exec.c |    5 +++++
 1 file changed, 5 insertions(+)

--- linux-2.6.28-rc9-mm1.orig/fs/exec.c
+++ linux-2.6.28-rc9-mm1/fs/exec.c
@@ -1809,10 +1809,15 @@ int do_coredump(long signr, int exit_cod
 	if ((!ispipe) && (core_limit < binfmt->min_coredump))
 		goto fail_unlock;
 
  	if (ispipe) {
 		helper_argv = argv_split(GFP_KERNEL, corename+1, &helper_argc);
+		if (!helper_argv) {
+			printk(KERN_WARNING "%s failed to allocate memory\n",
+			       __func__);
+			goto fail_unlock;
+		}
 		/* Terminate the string before the first option */
 		delimit = strchr(corename, ' ');
 		if (delimit)
 			*delimit = '\0';
 		delimit = strrchr(helper_argv[0], '/');

Re: [PATCH] Check return from argv_split() in do_coredump().

[Tetsuo Handa]

Hello.

Américo Wang wrote:
> How about going to the line:
> 
>         current->fsuid = fsuid;
> 
> ? Because when argv_split() fails, helper_argv is NULL and doesn't need
> to be checked again.

I didn't understand what you say. I'm saying that
"do_coredump() may accesss helper_argv[0] when helper_argv == NULL",
which will result in "NULL pointer dereference" problem.
Yes, this problem unlikely happens. Thus,

if (!helper_argv)
	goto fail_unlock;

may be enough.

Regards.

Re: [PATCH] Check return from argv_split() in do_coredump().

[Tetsuo Handa]

Hello.

Americo Wang wrote:
> fail_unlock:
>         if (helper_argv)
> 	                argv_free(helper_argv);
> 
>         current->fsuid = fsuid; //<=== goto this line
>         coredump_finish(mm);
> 
> You need to add a new label, of course. :)
> 
Ah, you were talking about destination of goto statement. I see.

Unfortunately, -mm source uses "revert_creds(old_cred); put_cred(cred);"
instead of "current->fsuid = fsuid;".
To keep this patch applicable to all afftected versions,
I'd like not to introduce a new label.

> if (helper_argv)
> 	                argv_free(helper_argv);
Well, I think it's better to check "if (helper_argv)" inside argv_free()
in case the caller forgets to check.

Regards.
--------------------
Subject: Check return from argv_split() in do_coredump().

do_coredump() accesses helper_argv[0] without checking helper_argv != NULL.
Though, likely helper_argv != NULL.

Below versions have this problem.

  2.6.24.7
  2.6.25.20
  2.6.26.8
  2.6.27.10
  2.6.28
  mmotm 2008-12-24-01-20

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
---
 fs/exec.c |    2 ++
 1 file changed, 2 insertions(+)

--- linux-2.6.28-rc9-mm1.orig/fs/exec.c
+++ linux-2.6.28-rc9-mm1/fs/exec.c
@@ -1808,6 +1808,8 @@ int do_coredump(long signr, int exit_cod
 
  	if (ispipe) {
 		helper_argv = argv_split(GFP_KERNEL, corename+1, &helper_argc);
+		if (!helper_argv)
+			goto fail_unlock;
 		/* Terminate the string before the first option */
 		delimit = strchr(corename, ' ');
 		if (delimit)

Re: [PATCH] Check return from argv_split() in do_coredump().

[KOSAKI Motohiro]

> --------------------
> Subject: Check return from argv_split() in do_coredump().
>
> do_coredump() accesses helper_argv[0] without checking helper_argv != NULL.
> Though, likely helper_argv != NULL.
>
> Below versions have this problem.
>
>  2.6.24.7
>  2.6.25.20
>  2.6.26.8
>  2.6.27.10
>  2.6.28
>  mmotm 2008-12-24-01-20

please remove target version from patch description (it is not useful
for git log).
and please cc to linux-stable.

otherthings, looks good to me.
   Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>

Re: [PATCH] Check return from argv_split() in do_coredump().

[Américo Wang]

On Wed, Dec 24, 2008 at 03:16:16PM +0900, Tetsuo Handa wrote:
>do_coredump() accesses helper_argv[0] without checking helper_argv != NULL.
>Though, likely helper_argv != NULL.
>
>Below versions have this problem.
>
>  2.6.24.7
>  2.6.25.20
>  2.6.26.8
>  2.6.27.10
>  2.6.28-rc9
>  mmotm 2008-12-22-16-14
>
>Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
>---
> fs/exec.c |    5 +++++
> 1 file changed, 5 insertions(+)
>
>--- linux-2.6.28-rc9-mm1.orig/fs/exec.c
>+++ linux-2.6.28-rc9-mm1/fs/exec.c
>@@ -1809,10 +1809,15 @@ int do_coredump(long signr, int exit_cod
> 	if ((!ispipe) && (core_limit < binfmt->min_coredump))
> 		goto fail_unlock;
> 
>  	if (ispipe) {
> 		helper_argv = argv_split(GFP_KERNEL, corename+1, &helper_argc);
>+		if (!helper_argv) {
>+			printk(KERN_WARNING "%s failed to allocate memory\n",
>+			       __func__);
>+			goto fail_unlock;

How about going to the line:

        current->fsuid = fsuid;

? Because when argv_split() fails, helper_argv is NULL and doesn't need
to be checked again.

Otherwise,

Reviewed-by: WANG Cong <wangcong@zeuux.org>

Thanks.

-- 
"Against stupidity, the gods themselves, contend in vain."

Re: [PATCH] Check return from argv_split() in do_coredump().

[Américo Wang]

On Fri, Dec 26, 2008 at 04:00:56PM +0900, Tetsuo Handa wrote:
>Hello.
>
>Am^[$(D+1rico Wang wrote:
>> How about going to the line:
>> 
>>         current->fsuid = fsuid;
>> 
>> ? Because when argv_split() fails, helper_argv is NULL and doesn't need
>> to be checked again.
>
>I didn't understand what you say. I'm saying that
>"do_coredump() may accesss helper_argv[0] when helper_argv == NULL",
>which will result in "NULL pointer dereference" problem.
>Yes, this problem unlikely happens. Thus,
>
>if (!helper_argv)
>	goto fail_unlock;
>
>may be enough.
>

Yes, goto fail_unlock will go to this line:

        if (helper_argv)
	                argv_free(helper_argv);

but in this situation, helper_argv is known as NULL, thus another
check doesn't need. So we can go to the line below, i.e.

fail_unlock:
        if (helper_argv)
	                argv_free(helper_argv);

        current->fsuid = fsuid; //<=== goto this line
        coredump_finish(mm);

You need to add a new label, of course. :)

-- 
"Against stupidity, the gods themselves, contend in vain."