This is a note to let you know that I've just added the patch titled
module: Clean up ro/nx after early module load failures
to the 3.16-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
module-clean-up-ro-nx-after-early-module-load-failures.patch
and it can be found in the queue-3.16 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <[email protected]> know about it.
>From ff7e0055bb5ddbbb320cdd8dfd3e18672bddd2ad Mon Sep 17 00:00:00 2001
From: Andy Lutomirski <[email protected]>
Date: Sat, 16 Aug 2014 04:13:37 +0930
Subject: module: Clean up ro/nx after early module load failures
From: Andy Lutomirski <[email protected]>
commit ff7e0055bb5ddbbb320cdd8dfd3e18672bddd2ad upstream.
The commit
4982223e51e8 module: set nx before marking module MODULE_STATE_COMING.
introduced a regression: if a module fails to parse its arguments or
if mod_sysfs_setup fails, then the module's memory will be freed
while still read-only. Anything that reuses that memory will crash
as soon as it tries to write to it.
Cc: Rusty Russell <[email protected]>
Signed-off-by: Andy Lutomirski <[email protected]>
Signed-off-by: Rusty Russell <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/module.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -3308,6 +3308,11 @@ static int load_module(struct load_info
mutex_lock(&module_mutex);
module_bug_cleanup(mod);
mutex_unlock(&module_mutex);
+
+ /* we can't deallocate the module until we clear memory protection */
+ unset_module_init_ro_nx(mod);
+ unset_module_core_ro_nx(mod);
+
ddebug_cleanup:
dynamic_debug_remove(info->debug);
synchronize_sched();
Patches currently in stable-queue which might be from [email protected] are
queue-3.16/module-clean-up-ro-nx-after-early-module-load-failures.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
