[Patch] kernel: bug fixing for kernel/kmod.c

[Patch] kernel: bug fixing for kernel/kmod.c

[kenny]

I think there is a bug in kmod.c. In __call_usermodehelper(), when 
kernel_thread(wait_for_helper, ...) return success, since
wait_for_helper() might call complete() at any time, the sub_info should
not be used any more.

the following patch is made in 2.6.17.7

--- kmod.c      2006-07-25 11:36:01.000000000 +0800
+++ /tmp/kmod.c 2006-08-02 01:01:42.702054000 +0800
@@ -198,6 +198,7 @@ static void __call_usermodehelper(void *
 {
        struct subprocess_info *sub_info = data;
        pid_t pid;
+       int wait = sub_info->wait;

        /* CLONE_VFORK: wait until the usermode helper has execve'd
         * successfully We need the data structures to stay around
@@ -212,7 +213,7 @@ static void __call_usermodehelper(void *
        if (pid < 0) {
                sub_info->retval = pid;
                complete(sub_info->complete);
-       } else if (!sub_info->wait)
+       } else if (!wait)
                complete(sub_info->complete);
 }

-- 

Re: [Patch] kernel: bug fixing for kernel/kmod.c

[Steven Rostedt]

On Wed, 2006-08-02 at 01:20 +0800, kenny wrote:
> I think there is a bug in kmod.c. In __call_usermodehelper(), when 
> kernel_thread(wait_for_helper, ...) return success, since
> wait_for_helper() might call complete() at any time, the sub_info should
> not be used any more.

Good catch!

The sub_info is on the stack of call_usermodehelper_keys and with wait
set, the wait_for_helper is called as a thread and does the complete and
there is a chance that the call_usermodehelper_keys will return and use
its stack for something else, before the helper finishes, making the
wait not valid anymore, and worst, using a bad complete.

On a normal case, the wait_for_helper will call something in userland
and this would most likely allow the caller to finish with a correct
wait.  But still this in incorrect code, since there can definitely be a
race here.

OK, now on submitting a patch :-)

1. read Documentation/SubmittingPatches

2. Linus will probably not even read this (although he might).
  So try to find a maintainer. And even on this file you see at the 
  top:

	call_usermodehelper wait flag, and remove exec_usermodehelper.
	Rusty Russell <rusty@rustcorp.com.au>  Jan 2003

Which means that Rusty was probably the one who wrote the code.

3. Use a -p1 patch format to submit.  IOW the files to compare against
should have been a/kernel/kmod.c  and not /tmp/kmod.c.

If you want a cool tool for making patches get quilt:

http://savannah.nongnu.org/projects/quilt

4. sign off your work by adding a "Signed-off-by: Full name <email@address>"


So please, fix up your patch and send it again properly :)

-- Steve


> 
> the following patch is made in 2.6.17.7
> 
> --- kmod.c      2006-07-25 11:36:01.000000000 +0800
> +++ /tmp/kmod.c 2006-08-02 01:01:42.702054000 +0800
> @@ -198,6 +198,7 @@ static void __call_usermodehelper(void *
>  {
>         struct subprocess_info *sub_info = data;
>         pid_t pid;
> +       int wait = sub_info->wait;
> 
>         /* CLONE_VFORK: wait until the usermode helper has execve'd
>          * successfully We need the data structures to stay around
> @@ -212,7 +213,7 @@ static void __call_usermodehelper(void *
>         if (pid < 0) {
>                 sub_info->retval = pid;
>                 complete(sub_info->complete);
> -       } else if (!sub_info->wait)
> +       } else if (!wait)
>                 complete(sub_info->complete);
>  }

[Patch] kernel: bug fixing for kernel/kmod.c

[Kenneth Lee]

I think there is a bug in kmod.c: In __call_usermodehelper(), when 
kernel_thread(wait_for_helper, ...) return success, since
wait_for_helper() might call complete() at any time, the sub_info should
not be used any more.

Normally wait_for_helper() take a long time to finish, you may not get 
problem for most of the case. But if you remove /sbin/modprobe, it may
become easier for you to get a oop in khelper.

the following patch is made in 2.6.17.7

--- linux-2.6.17.7/kernel/kmod.c.orig   2006-08-02 22:13:21.805902750
+0800
+++ linux-2.6.17.7/kernel/kmod.c        2006-08-02 22:15:36.946348500
+0800
@@ -198,6 +198,7 @@ static void __call_usermodehelper(void *
 {
        struct subprocess_info *sub_info = data;
        pid_t pid;
+       int wait = sub_info->wait;

        /* CLONE_VFORK: wait until the usermode helper has execve'd
         * successfully We need the data structures to stay around
@@ -212,7 +213,7 @@ static void __call_usermodehelper(void *
        if (pid < 0) {
                sub_info->retval = pid;
                complete(sub_info->complete);
-       } else if (!sub_info->wait)
+       } else if (!wait)
                complete(sub_info->complete);
 }

-- 

Re: [Patch] kernel: bug fixing for kernel/kmod.c

[Kenneth Lee]

Mr. Rusty Russell's mail server reject my mail. Anybody can tell me
where I should deliver the patch?

On Wed, Aug 02, 2006 at 10:30:46PM +0800, Kenneth Lee wrote:
> Subject: [Patch] kernel: bug fixing for kernel/kmod.c
> 
> I think there is a bug in kmod.c: In __call_usermodehelper(), when 
> kernel_thread(wait_for_helper, ...) return success, since
> wait_for_helper() might call complete() at any time, the sub_info should
> not be used any more.
> 
> Normally wait_for_helper() take a long time to finish, you may not get 
> problem for most of the case. But if you remove /sbin/modprobe, it may
> become easier for you to get a oop in khelper.
> 
> the following patch is made in 2.6.17.7
> 
> --- linux-2.6.17.7/kernel/kmod.c.orig   2006-08-02 22:13:21.805902750
> +0800
> +++ linux-2.6.17.7/kernel/kmod.c        2006-08-02 22:15:36.946348500
> +0800
> @@ -198,6 +198,7 @@ static void __call_usermodehelper(void *
>  {
>         struct subprocess_info *sub_info = data;
>         pid_t pid;
> +       int wait = sub_info->wait;
> 
>         /* CLONE_VFORK: wait until the usermode helper has execve'd
>          * successfully We need the data structures to stay around
> @@ -212,7 +213,7 @@ static void __call_usermodehelper(void *
>         if (pid < 0) {
>                 sub_info->retval = pid;
>                 complete(sub_info->complete);
> -       } else if (!sub_info->wait)
> +       } else if (!wait)
>                 complete(sub_info->complete);
>  }
> 
> -- 

-- 

Re: [Patch] kernel: bug fixing for kernel/kmod.c

[Matt Helsley]

On Wed, 2006-08-02 at 22:30 +0800, Kenneth Lee wrote:
> I think there is a bug in kmod.c: In __call_usermodehelper(), when 
> kernel_thread(wait_for_helper, ...) return success, since
> wait_for_helper() might call complete() at any time, the sub_info should
> not be used any more.
> 
> Normally wait_for_helper() take a long time to finish, you may not get 
> problem for most of the case. But if you remove /sbin/modprobe, it may
> become easier for you to get a oop in khelper.
> 
> the following patch is made in 2.6.17.7
> 
> --- linux-2.6.17.7/kernel/kmod.c.orig   2006-08-02 22:13:21.805902750
> +0800
> +++ linux-2.6.17.7/kernel/kmod.c        2006-08-02 22:15:36.946348500
> +0800
> @@ -198,6 +198,7 @@ static void __call_usermodehelper(void *
>  {
>         struct subprocess_info *sub_info = data;
>         pid_t pid;
> +       int wait = sub_info->wait;
> 
>         /* CLONE_VFORK: wait until the usermode helper has execve'd
>          * successfully We need the data structures to stay around
> @@ -212,7 +213,7 @@ static void __call_usermodehelper(void *
>         if (pid < 0) {
>                 sub_info->retval = pid;
>                 complete(sub_info->complete);
> -       } else if (!sub_info->wait)
> +       } else if (!wait)
>                 complete(sub_info->complete);
>  }
> 

Looks like a correct fix for the race to me. I think you'd make the code
slightly easier to read by replacing the initial test too:

if (sub_info->wait)
	pid = kernel_thread(...

with:

if (wait)
	pid = kernel_thread(...

Cheers,
	-Matt Helsley