linux-kernel - Re: PATCH] debug: add notifier chain debugging

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: <20080819210932.9bb348b9.akpm@linux-foundation.org>
Date:	Tue, 19 Aug 2008 21:09:32 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	linux-kernel@...r.kernel.org, mingo@...e.hu
Subject: Re: PATCH] debug: add notifier chain debugging

On Fri, 15 Aug 2008 15:29:38 -0700 Arjan van de Ven <arjan@...radead.org> wrote:

> From: Arjan van de Ven <arjan@...ux.intel.com>
> Subject: [PATCH] debug: add notifier chain debugging
> 
> during some development we suspected a case where we left something
> in a notifier chain that was from a module that was unloaded already...
> and that sort of thing is rather hard to track down.
> 
> This patch adds a very simple sanity check (which isn't all that
> expensive) to make sure the notifier we're about to call is
> actually from either the kernel itself of from a still-loaded
> module, avoiding a hard-to-chase-down crash.
> 
> Signed-off-by: Arjan van de Ven <arjan@...ux.intel.com>
> ---
>  kernel/notifier.c |   16 ++++++++++++++++
>  lib/Kconfig.debug |   10 ++++++++++
>  2 files changed, 26 insertions(+), 0 deletions(-)
> 
> diff --git a/kernel/notifier.c b/kernel/notifier.c
> index 823be11..143fdd7 100644
> --- a/kernel/notifier.c
> +++ b/kernel/notifier.c
> @@ -21,6 +21,10 @@ BLOCKING_NOTIFIER_HEAD(reboot_notifier_list);
>  static int notifier_chain_register(struct notifier_block **nl,
>  		struct notifier_block *n)
>  {
> +	if (!kernel_text_address((unsigned long)n->notifier_call)) {
> +		WARN(1, "Invalid notifier registered!");
> +		return 0;
> +	}
>  	while ((*nl) != NULL) {
>  		if (n->priority > (*nl)->priority)
>  			break;
> @@ -34,6 +38,10 @@ static int notifier_chain_register(struct notifier_block **nl,
>  static int notifier_chain_cond_register(struct notifier_block **nl,
>  		struct notifier_block *n)
>  {
> +	if (!kernel_text_address((unsigned long)n->notifier_call)) {
> +		WARN(1, "Invalid notifier registered!");
> +		return 0;
> +	}

Seems strange to add checks to the registration functions.  What could
be that broken?

>  	while ((*nl) != NULL) {
>  		if ((*nl) == n)
>  			return 0;
> @@ -82,6 +90,14 @@ static int __kprobes notifier_call_chain(struct notifier_block **nl,
>  
>  	while (nb && nr_to_call) {
>  		next_nb = rcu_dereference(nb->next);
> +
> +#ifdef CONFIG_DEBUG_NOTIFIERS
> +		if (!kernel_text_address((unsigned long)nb->notifier_call)) {
> +			WARN(1, "Invalid notifier called!");
> +			nb = next_nb;
> +			continue;
> +		}
> +#endif
>  		ret = nb->notifier_call(nb, val, v);
>  
>  		if (nr_calls)
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 800ac84..f4bb36e 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -536,6 +536,16 @@ config DEBUG_SG
>  
>  	  If unsure, say N.
>  
> +config DEBUG_NOTIFIERS
> +	bool "Debug notifier call chains"
> +	depends on DEBUG_KERNEL
> +	help
> +	  Enable this to turn on sanity checking for notifier call chains.
> +	  This is most useful for kernel developers to make sure that
> +	  modules properly unregister themselves from notifier chains.
> +	  This is a relatively cheap check but if you care about maximum
> +	  performance, say N.
> +

If we remove the first two checks then surely we can afford to add the
remaining check unconditionally and lose the new config option and its
ifdef.

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