Re: [RFC 02/10] module: fix memory leak on early load_module() failures
On Fri, Dec 09, 2016 at 06:06:44PM +0100, Miroslav Benes wrote:
>
> Reviewed-by: Miroslav Benes
>
> What about
>
> Fixes: e180a6b7759a ("param: fix charp parameters set via sysfs")
>
> ?
Sure thing, added thanks!
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 02/10] module: fix memory leak on early load_module() failures
On Thu 2016-12-08 11:48 -0800, Luis R. Rodriguez wrote: > While looking for early possible module loading failures I was > able to reproduce a memory leak possible with kmemleak. There > are a few rare ways to trigger a failure: > > o we've run into a failure while processing kernel parameters > (parse_args() returns an error) > o mod_sysfs_setup() fails > o we're a live patch module and copy_module_elf() fails > > Chances of running into this issue is really low. > > kmemleak splat: > > unreferenced object 0x9f2c4ada1b00 (size 32): > comm "kworker/u16:4", pid 82, jiffies 4294897636 (age 681.816s) > hex dump (first 32 bytes): > 6d 65 6d 73 74 69 63 6b 30 00 00 00 00 00 00 00 memstick0... > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > backtrace: > [] kmemleak_alloc+0x4a/0xa0 > [] __kmalloc_track_caller+0x126/0x230 > [] kstrdup+0x31/0x60 > [] kstrdup_const+0x24/0x30 > [] kvasprintf_const+0x7a/0x90 > [] kobject_set_name_vargs+0x21/0x90 > [] dev_set_name+0x47/0x50 > [] memstick_check+0x95/0x33c [memstick] > [] process_one_work+0x1f3/0x4b0 > [] worker_thread+0x48/0x4e0 > [] kthread+0xc9/0xe0 > [] ret_from_fork+0x1f/0x40 > [] 0x > > Signed-off-by: Luis R. Rodriguez > --- > kernel/module.c | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Aaron Tomlin -- Aaron Tomlin signature.asc Description: PGP signature
Re: [RFC 02/10] module: fix memory leak on early load_module() failures
On Thu, 8 Dec 2016, Luis R. Rodriguez wrote:
> While looking for early possible module loading failures I was
> able to reproduce a memory leak possible with kmemleak. There
> are a few rare ways to trigger a failure:
>
> o we've run into a failure while processing kernel parameters
> (parse_args() returns an error)
> o mod_sysfs_setup() fails
> o we're a live patch module and copy_module_elf() fails
>
> Chances of running into this issue is really low.
>
> kmemleak splat:
>
> unreferenced object 0x9f2c4ada1b00 (size 32):
> comm "kworker/u16:4", pid 82, jiffies 4294897636 (age 681.816s)
> hex dump (first 32 bytes):
> 6d 65 6d 73 74 69 63 6b 30 00 00 00 00 00 00 00 memstick0...
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> backtrace:
> [] kmemleak_alloc+0x4a/0xa0
> [] __kmalloc_track_caller+0x126/0x230
> [] kstrdup+0x31/0x60
> [] kstrdup_const+0x24/0x30
> [] kvasprintf_const+0x7a/0x90
> [] kobject_set_name_vargs+0x21/0x90
> [] dev_set_name+0x47/0x50
> [] memstick_check+0x95/0x33c [memstick]
> [] process_one_work+0x1f3/0x4b0
> [] worker_thread+0x48/0x4e0
> [] kthread+0xc9/0xe0
> [] ret_from_fork+0x1f/0x40
> [] 0x
>
> Signed-off-by: Luis R. Rodriguez
Reviewed-by: Miroslav Benes
What about
Fixes: e180a6b7759a ("param: fix charp parameters set via sysfs")
?
Miroslav
> ---
> kernel/module.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/kernel/module.c b/kernel/module.c
> index f7482db0f843..e420ed67e533 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -3722,6 +3722,7 @@ static int load_module(struct load_info *info, const
> char __user *uargs,
> mod_sysfs_teardown(mod);
> coming_cleanup:
> mod->state = MODULE_STATE_GOING;
> + destroy_params(mod->kp, mod->num_kp);
> blocking_notifier_call_chain(&module_notify_list,
>MODULE_STATE_GOING, mod);
> klp_module_going(mod);
> --
> 2.10.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 02/10] module: fix memory leak on early load_module() failures
On Thu, Dec 8, 2016 at 1:10 PM, Luis R. Rodriguez wrote: > On Thu, Dec 8, 2016 at 2:30 PM, Kees Cook wrote: >> On Thu, Dec 8, 2016 at 11:48 AM, Luis R. Rodriguez wrote: >>> While looking for early possible module loading failures I was >>> able to reproduce a memory leak possible with kmemleak. There >>> are a few rare ways to trigger a failure: >>> >>> o we've run into a failure while processing kernel parameters >>> (parse_args() returns an error) >>> o mod_sysfs_setup() fails >>> o we're a live patch module and copy_module_elf() fails >>> >>> Chances of running into this issue is really low. >>> >>> kmemleak splat: >>> >>> unreferenced object 0x9f2c4ada1b00 (size 32): >>> comm "kworker/u16:4", pid 82, jiffies 4294897636 (age 681.816s) >>> hex dump (first 32 bytes): >>> 6d 65 6d 73 74 69 63 6b 30 00 00 00 00 00 00 00 memstick0... >>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> backtrace: >>> [] kmemleak_alloc+0x4a/0xa0 >>> [] __kmalloc_track_caller+0x126/0x230 >>> [] kstrdup+0x31/0x60 >>> [] kstrdup_const+0x24/0x30 >>> [] kvasprintf_const+0x7a/0x90 >>> [] kobject_set_name_vargs+0x21/0x90 >>> [] dev_set_name+0x47/0x50 >>> [] memstick_check+0x95/0x33c [memstick] >>> [] process_one_work+0x1f3/0x4b0 >>> [] worker_thread+0x48/0x4e0 >>> [] kthread+0xc9/0xe0 >>> [] ret_from_fork+0x1f/0x40 >>> [] 0x >>> >>> Signed-off-by: Luis R. Rodriguez >> >> Acked-by: Kees Cook >> >> Is this worth sending through -stable too? > > Yes, for some reason git-send e-mail complained to me about > sta...@kernel.org not being a valid local address, so I had to remove > it, but indeed. I'll try to fix this e-mail issue later and add your > tag. Yup, you want sta...@vger.kernel.org. :) -Kees -- Kees Cook Nexus Security -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 02/10] module: fix memory leak on early load_module() failures
On Thu, Dec 8, 2016 at 2:30 PM, Kees Cook wrote: > On Thu, Dec 8, 2016 at 11:48 AM, Luis R. Rodriguez wrote: >> While looking for early possible module loading failures I was >> able to reproduce a memory leak possible with kmemleak. There >> are a few rare ways to trigger a failure: >> >> o we've run into a failure while processing kernel parameters >> (parse_args() returns an error) >> o mod_sysfs_setup() fails >> o we're a live patch module and copy_module_elf() fails >> >> Chances of running into this issue is really low. >> >> kmemleak splat: >> >> unreferenced object 0x9f2c4ada1b00 (size 32): >> comm "kworker/u16:4", pid 82, jiffies 4294897636 (age 681.816s) >> hex dump (first 32 bytes): >> 6d 65 6d 73 74 69 63 6b 30 00 00 00 00 00 00 00 memstick0... >> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> backtrace: >> [] kmemleak_alloc+0x4a/0xa0 >> [] __kmalloc_track_caller+0x126/0x230 >> [] kstrdup+0x31/0x60 >> [] kstrdup_const+0x24/0x30 >> [] kvasprintf_const+0x7a/0x90 >> [] kobject_set_name_vargs+0x21/0x90 >> [] dev_set_name+0x47/0x50 >> [] memstick_check+0x95/0x33c [memstick] >> [] process_one_work+0x1f3/0x4b0 >> [] worker_thread+0x48/0x4e0 >> [] kthread+0xc9/0xe0 >> [] ret_from_fork+0x1f/0x40 >> [] 0x >> >> Signed-off-by: Luis R. Rodriguez > > Acked-by: Kees Cook > > Is this worth sending through -stable too? Yes, for some reason git-send e-mail complained to me about sta...@kernel.org not being a valid local address, so I had to remove it, but indeed. I'll try to fix this e-mail issue later and add your tag. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 02/10] module: fix memory leak on early load_module() failures
On Thu, Dec 8, 2016 at 11:48 AM, Luis R. Rodriguez wrote: > While looking for early possible module loading failures I was > able to reproduce a memory leak possible with kmemleak. There > are a few rare ways to trigger a failure: > > o we've run into a failure while processing kernel parameters > (parse_args() returns an error) > o mod_sysfs_setup() fails > o we're a live patch module and copy_module_elf() fails > > Chances of running into this issue is really low. > > kmemleak splat: > > unreferenced object 0x9f2c4ada1b00 (size 32): > comm "kworker/u16:4", pid 82, jiffies 4294897636 (age 681.816s) > hex dump (first 32 bytes): > 6d 65 6d 73 74 69 63 6b 30 00 00 00 00 00 00 00 memstick0... > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > backtrace: > [] kmemleak_alloc+0x4a/0xa0 > [] __kmalloc_track_caller+0x126/0x230 > [] kstrdup+0x31/0x60 > [] kstrdup_const+0x24/0x30 > [] kvasprintf_const+0x7a/0x90 > [] kobject_set_name_vargs+0x21/0x90 > [] dev_set_name+0x47/0x50 > [] memstick_check+0x95/0x33c [memstick] > [] process_one_work+0x1f3/0x4b0 > [] worker_thread+0x48/0x4e0 > [] kthread+0xc9/0xe0 > [] ret_from_fork+0x1f/0x40 > [] 0x > > Signed-off-by: Luis R. Rodriguez Acked-by: Kees Cook Is this worth sending through -stable too? -Kees > --- > kernel/module.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/kernel/module.c b/kernel/module.c > index f7482db0f843..e420ed67e533 100644 > --- a/kernel/module.c > +++ b/kernel/module.c > @@ -3722,6 +3722,7 @@ static int load_module(struct load_info *info, const > char __user *uargs, > mod_sysfs_teardown(mod); > coming_cleanup: > mod->state = MODULE_STATE_GOING; > + destroy_params(mod->kp, mod->num_kp); > blocking_notifier_call_chain(&module_notify_list, > MODULE_STATE_GOING, mod); > klp_module_going(mod); > -- > 2.10.1 > -- Kees Cook Nexus Security -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
