Skip to contentSkip to conversation

kernel: bug fixing for kernel/kmod.c

PATCH In review kenny 2 participants 2 messages Aug 1, 2006

lore
Share & tools
lore

kenny

author
#0 lore raw

PATCH 1/1 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.

the following patch is made in 2.6.17.7

tmp/kmod.c 2006-08-02 01:01:42.702054000 +0800 renamed from kmod.c 2006-07-25 11:36:01.000000000 +0800 +2 -1
@@ -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);
 }
 
#1 lore raw
Quoted 4 lines · 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.

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 <[email protected]> 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

Quoted 21 lines

the following patch is made in 2.6.17.7

tmp/kmod.c 2006-08-02 01:01:42.702054000 +0800 renamed from kmod.c 2006-07-25 11:36:01.000000000 +0800 +2 -1
@@ -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);
 }