Bug 9578
Summary: | Returning from a function with a pointer to a local variable on kernel/kmod.c | ||
---|---|---|---|
Product: | Other | Reporter: | Marcio Buss (marciobuss) |
Component: | Modules | Assignee: | other_modules |
Status: | REJECTED INVALID | ||
Severity: | low | CC: | oleg |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.23 | Subsystem: | |
Regression: | --- | Bisected commit-id: |
Description
Marcio Buss
2007-12-15 14:12:07 UTC
> This is a low severity bug, Well, I am not sure this is bug. > (2) the test at line 471 is true, making the procedure to return. > > sub_info->complete now points-to "done," which has been deallocated. We return when wait == UMH_NO_WAIT, but UMH_NO_WAIT means "don't wait" and thus "don't use info->complete". Please close this bug unless you see other problems. Sure, I will close the bug. PS1.: You are right, it is not a bug---but referring to a deallocated block of memory makes "bugs-to-be" happy :) On 12/16, bugme-daemon@bugzilla.kernel.org wrote: > > but referring > to a deallocated block of memory makes "bugs-to-be" > happy :) Yes, you are right. And this "/* task has freed sub_info */" comment is obviously wrong. We can do something like if (wait != UMH_NO_WAIT) sub_info->complete = &done; sub_info->wait = wait; ... but then another automatic tool can report the "possible usage of uninitialized subprocess_info->complete". And the code above imho is more unclear compared to what we currently have. Just in case, coredump_wait() sets ->core_startup_done = startup_done and returns if zap_threads() fails. Not a bug ;) In any case, thanks for these reports. The extra review is always better than a missed bug. Oleg. |