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