lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201107050124.p651OExY025046@www262.sakura.ne.jp>
Date:	Tue, 05 Jul 2011 10:24:14 +0900
From:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To:	richard@....at
Cc:	viro@...iv.linux.org.uk, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH][Resend v2] Fix infinite loop in search_binary_handler()

Richard Weinberger wrote:
> With MAX_KMOD_CONCURRENT=3 it takes only a few seconds until 
> the modprobe storm ends.

OK. Many years ago, I got a few reports that the kernel panics after printing

  request_module: runaway loop modprobe binfmt-464c

line. This was because they installed by error a binary x86_32 kernel rpm on
x86_64 userland tools. So, this error is not specific to UML.

> How shall we proceed?
> Applying my ad-hoc patch 
> or lowering MAX_KMOD_CONCURRENT?

What about disallowing request_module() for ____call_usermodehelper() threads?

diff --git a/include/linux/sched.h b/include/linux/sched.h
index a837b20..70b52de 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1289,6 +1289,7 @@ struct task_struct {
 	unsigned did_exec:1;
 	unsigned in_execve:1;	/* Tell the LSMs that the process is doing an
 				 * execve */
+	unsigned no_request_module:1; /* Disallow request_module() calls. */
 	unsigned in_iowait:1;
 
 
diff --git a/kernel/kmod.c b/kernel/kmod.c
index 47613df..32ad87c 100644
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -88,6 +88,8 @@ int __request_module(bool wait, const char *fmt, ...)
 #define MAX_KMOD_CONCURRENT 50	/* Completely arbitrary value - KAO */
 	static int kmod_loop_msg;
 
+	if (current->no_request_module)
+		return -ENOSYS;
 	va_start(args, fmt);
 	ret = vsnprintf(module_name, MODULE_NAME_LEN, fmt, args);
 	va_end(args);
@@ -177,6 +179,7 @@ static int ____call_usermodehelper(void *data)
 
 	commit_creds(new);
 
+	current->no_request_module = 1;
 	retval = kernel_execve(sub_info->path,
 			       (const char *const *)sub_info->argv,
 			       (const char *const *)sub_info->envp);
diff --git a/fs/exec.c b/fs/exec.c
index 6075a1e..b949387 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1387,6 +1387,7 @@ int search_binary_handler(struct linux_binprm *bprm,struct pt_regs *regs)
 				if (bprm->file)
 					fput(bprm->file);
 				bprm->file = NULL;
+				current->no_request_module = 0;
 				current->did_exec = 1;
 				proc_exec_connector(current);
 				return retval;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ