Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160817091652.59fa2668@gandalf.local.home>
Date: Wed, 17 Aug 2016 09:16:52 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Kees Cook <keescook@...omium.org>
Cc: "Paul E . McKenney" <paulmck@...ux.vnet.ibm.com>, Laura Abbott
 <labbott@...hat.com>, Stephen Boyd <sboyd@...eaurora.org>, Daniel Micay
 <danielmicay@...il.com>, Joe Perches <joe@...ches.com>, Arnd Bergmann
 <arnd@...db.de>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Josh
 Triplett <josh@...htriplett.org>, Mathieu Desnoyers
 <mathieu.desnoyers@...icios.com>, Lai Jiangshan <jiangshanlai@...il.com>,
 "Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>, "Kirill A. Shutemov"
 <kirill.shutemov@...ux.intel.com>, Michael Ellerman <mpe@...erman.id.au>,
 Dan Williams <dan.j.williams@...el.com>, Andrew Morton
 <akpm@...ux-foundation.org>, Ingo Molnar <mingo@...nel.org>, Thomas
 Gleixner <tglx@...utronix.de>, Josef Bacik <jbacik@...com>, Andrey Ryabinin
 <aryabinin@...tuozzo.com>, Tejun Heo <tj@...nel.org>, Nikolay Aleksandrov
 <nikolay@...ulusnetworks.com>, Dmitry Vyukov <dvyukov@...gle.com>,
 linux-kernel@...r.kernel.org, kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH v2 1/5] list: Split list_add() debug checking into
 separate function

On Tue, 16 Aug 2016 17:20:25 -0700
Kees Cook <keescook@...omium.org> wrote:

> Right now, __list_add() code is repeated either in list.h or in
> list_debug.c, but only the debug checks are the different part. This
> extracts the checking into a separate function and consolidates
> __list_add(). Additionally this __list_add_debug() will stop list
> manipulations if a corruption is detected, instead of allowing for further
> corruption that may lead to even worse conditions.
> 
> This is slight refactoring of the same hardening done in PaX and Grsecurity.
> 
> Signed-off-by: Kees Cook <keescook@...omium.org>
> ---
>  include/linux/list.h | 22 ++++++++++++++++------
>  lib/list_debug.c     | 48 +++++++++++++++++++++++-------------------------
>  2 files changed, 39 insertions(+), 31 deletions(-)
> 
> diff --git a/include/linux/list.h b/include/linux/list.h
> index 5183138aa932..0ed58591538e 100644
> --- a/include/linux/list.h
> +++ b/include/linux/list.h
> @@ -28,27 +28,37 @@ static inline void INIT_LIST_HEAD(struct list_head *list)
>  	list->prev = list;
>  }
>  
> +#ifdef CONFIG_DEBUG_LIST
> +extern bool __list_add_valid(struct list_head *new,
> +			      struct list_head *prev,
> +			      struct list_head *next);
> +#else
> +static inline bool __list_add_valid(struct list_head *new,
> +				struct list_head *prev,
> +				struct list_head *next)
> +{
> +	return true;
> +}
> +#endif
> +
>  /*
>   * Insert a new entry between two known consecutive entries.
>   *
>   * This is only for internal list manipulation where we know
>   * the prev/next entries already!
>   */
> -#ifndef CONFIG_DEBUG_LIST
>  static inline void __list_add(struct list_head *new,
>  			      struct list_head *prev,
>  			      struct list_head *next)
>  {
> +	if (!__list_add_valid(new, prev, next))
> +		return;
> +
>  	next->prev = new;
>  	new->next = next;
>  	new->prev = prev;
>  	WRITE_ONCE(prev->next, new);
>  }
> -#else
> -extern void __list_add(struct list_head *new,
> -			      struct list_head *prev,
> -			      struct list_head *next);
> -#endif
>  
>  /**
>   * list_add - add a new entry
> diff --git a/lib/list_debug.c b/lib/list_debug.c
> index 3859bf63561c..149dd57b583b 100644
> --- a/lib/list_debug.c
> +++ b/lib/list_debug.c
> @@ -2,8 +2,7 @@
>   * Copyright 2006, Red Hat, Inc., Dave Jones
>   * Released under the General Public License (GPL).
>   *
> - * This file contains the linked list implementations for
> - * DEBUG_LIST.
> + * This file contains the linked list validation for DEBUG_LIST.
>   */
>  
>  #include <linux/export.h>
> @@ -13,33 +12,32 @@
>  #include <linux/rculist.h>
>  
>  /*
> - * Insert a new entry between two known consecutive entries.
> - *
> - * This is only for internal list manipulation where we know
> - * the prev/next entries already!
> + * Check that the data structures for the list manipulations are reasonably
> + * valid. Failures here indicate memory corruption (and possibly an exploit
> + * attempt).
>   */
>  
> -void __list_add(struct list_head *new,
> -			      struct list_head *prev,
> -			      struct list_head *next)
> +bool __list_add_valid(struct list_head *new, struct list_head *prev,
> +		      struct list_head *next)
>  {
> -	WARN(next->prev != prev,
> -		"list_add corruption. next->prev should be "
> -		"prev (%p), but was %p. (next=%p).\n",
> -		prev, next->prev, next);
> -	WARN(prev->next != next,
> -		"list_add corruption. prev->next should be "
> -		"next (%p), but was %p. (prev=%p).\n",
> -		next, prev->next, prev);
> -	WARN(new == prev || new == next,
> -	     "list_add double add: new=%p, prev=%p, next=%p.\n",
> -	     new, prev, next);
> -	next->prev = new;
> -	new->next = next;
> -	new->prev = prev;
> -	WRITE_ONCE(prev->next, new);
> +	if (unlikely(next->prev != prev)) {
> +		WARN(1, "list_add corruption. next->prev should be prev (%p), but was %p. (next=%p).\n",
> +			prev, next->prev, next);
> +		return false;

BTW, WARN() does return the result, thus you could have just wrapped the
if () around them:

	if (WARN(next->prev != prev,
			"list_add corruption. next->prev should be prev (%p), but was %p. (next=%p).\n",
			prev, next->prev, next))
		return;

Just FYI.

-- Steve


> +	}
> +	if (unlikely(prev->next != next)) {
> +		WARN(1, "list_add corruption. prev->next should be next (%p), but was %p. (prev=%p).\n",
> +			next, prev->next, prev);
> +		return false;
> +	}
> +	if (unlikely(new == prev || new == next)) {
> +		WARN(1, "list_add double add: new=%p, prev=%p, next=%p.\n",
> +			new, prev, next);
> +		return false;
> +	}
> +	return true;
>  }
> -EXPORT_SYMBOL(__list_add);
> +EXPORT_SYMBOL(__list_add_valid);
>  
>  void __list_del_entry(struct list_head *entry)
>  {

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.