linux-kernel - [tip:sched/urgent] sched: Fix end_of_stack() and location of stack canary for architectures using CONFIG_STACK

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] [day] [month] [year] [list]

Message-ID: <tip-6a40281ab5c1ed8ba2253857118a5d400a2d084b@git.kernel.org>
Date:	Sat, 20 Sep 2014 10:45:35 -0700
From:	tip-bot for Chuck Ebbert <tipbot@...or.com>
To:	linux-tip-commits@...r.kernel.org
Cc:	linux-kernel@...r.kernel.org, hpa@...or.com, mingo@...nel.org,
	cebbert.lkml@...il.com, james.hogan@...tec.com, atomlin@...hat.com,
	tglx@...utronix.de
Subject: [tip:sched/urgent] sched: Fix end_of_stack()
  and location of stack canary for architectures using CONFIG_STACK_GROWSUP

Commit-ID:  6a40281ab5c1ed8ba2253857118a5d400a2d084b
Gitweb:     http://git.kernel.org/tip/6a40281ab5c1ed8ba2253857118a5d400a2d084b
Author:     Chuck Ebbert <cebbert.lkml@...il.com>
AuthorDate: Sat, 20 Sep 2014 10:17:51 -0500
Committer:  Ingo Molnar <mingo@...nel.org>
CommitDate: Sat, 20 Sep 2014 19:44:04 +0200

sched: Fix end_of_stack() and location of stack canary for architectures using CONFIG_STACK_GROWSUP

Aaron Tomlin recently posted patches [1] to enable checking the
stack canary on every task switch. Looking at the canary code, I
realized that every arch (except ia64, which adds some space for
register spill above the stack) shares a definition of
end_of_stack() that makes it the first long after the
threadinfo.

For stacks that grow down, this low address is correct because
the stack starts at the end of the thread area and grows toward
lower addresses. However, for stacks that grow up, toward higher
addresses, this is wrong. (The stack actually grows away from
the canary.) On these archs end_of_stack() should return the
address of the last long, at the highest possible address for the stack.

[1] http://lkml.org/lkml/2014/9/12/293

Signed-off-by: Chuck Ebbert <cebbert.lkml@...il.com>
Link: http://lkml.kernel.org/r/20140920101751.6c5166b6@as
Signed-off-by: Ingo Molnar <mingo@...nel.org>
Tested-by: James Hogan <james.hogan@...tec.com> [metag]
Acked-by: James Hogan <james.hogan@...tec.com>
Acked-by: Aaron Tomlin <atomlin@...hat.com>
---
 include/linux/sched.h | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 5c2c885..1f07040 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2608,9 +2608,22 @@ static inline void setup_thread_stack(struct task_struct *p, struct task_struct
 	task_thread_info(p)->task = p;
 }
 
+/*
+ * Return the address of the last usable long on the stack.
+ *
+ * When the stack grows down, this is just above the thread
+ * info struct. Going any lower will corrupt the threadinfo.
+ *
+ * When the stack grows up, this is the highest address.
+ * Beyond that position, we corrupt data on the next page.
+ */
 static inline unsigned long *end_of_stack(struct task_struct *p)
 {
+#ifdef CONFIG_STACK_GROWSUP
+	return (unsigned long *)((unsigned long)task_thread_info(p) + THREAD_SIZE) - 1;
+#else
 	return (unsigned long *)(task_thread_info(p) + 1);
+#endif
 }
 
 #endif
--
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/