linux-kernel - Re: [PATCH] kprobes: bugfix: try_module_get even if calling

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: <20081106170023.d5349c42.akpm@linux-foundation.org>
Date:	Thu, 6 Nov 2008 17:00:23 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Masami Hiramatsu <mhiramat@...hat.com>
Cc:	h-shimamoto@...jp.nec.com, ananth@...ibm.com, laijs@...fujitsu.com,
	davem@...emloft.net, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] kprobes: bugfix: try_module_get even if calling_mod is
 NULL

On Wed, 05 Nov 2008 19:06:57 -0500
Masami Hiramatsu <mhiramat@...hat.com> wrote:

> Get probed module even if the caller is in the kernel core code.
> 
> Signed-off-by: Masami Hiramatsu <mhiramat@...hat.com>
> ---
> 
> >> One question, off topic.
> >> If calling_mod is NULL, no try_module_get(), is that OK?
> >
> > Good question. Currently, kprobes is called only from kernel modules,
> > so calling_mod should be always !NULL.
> > However, it should be fixed, because the logic is not correct.
> 
> Thank you so much. So here is the additional bugfix patch.
> 
>  kernel/kprobes.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: 2.6.28-rc3/kernel/kprobes.c
> ===================================================================
> --- 2.6.28-rc3.orig/kernel/kprobes.c
> +++ 2.6.28-rc3/kernel/kprobes.c
> @@ -634,7 +634,7 @@ static int __kprobes __register_kprobe(s
>  		 * avoid incrementing the module refcount, so as to allow
>  		 * unloading of self probing modules.
>  		 */
> -		if (calling_mod && calling_mod != probed_mod) {
> +		if (calling_mod != probed_mod) {
>  			if (unlikely(!try_module_get(probed_mod))) {
>  				preempt_enable();
>  				return -EINVAL;
> 

I do not understand this description "Get probed module even if the
caller is in the kernel core code".

What bug is being fixed here?  What is the kernel behaviour before and
after the patch?

Was the bug present in 2.6.27, 2.6.26 etc?  Or was it a post-2.6.28
regression?

--
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/