| From: |
| Aaron Tomlin <atomlin@redhat.com> |
| To: |
| peterz@infradead.org |
| Subject: |
| [PATCH v2 0/3] sched: Always check the integrity of the canary |
| Date: |
| Mon, 8 Sep 2014 20:23:14 +0100 |
| Message-ID: |
| <1410204197-31204-1-git-send-email-atomlin@redhat.com> |
| Cc: |
| mingo@redhat.com, dzickus@redhat.com, bmr@redhat.com, jcastillo@redhat.com, atomlin@redhat.com, oleg@redhat.com, pzijlstr@redhat.com, riel@redhat.com, linux-kernel@vger.kernel.org, tglx@linutronix.de, x86@kernel.org, rostedt@goodmis.org, hannes@cmpxchg.org, aneesh.kumar@linux.vnet.ibm.com, akpm@linux-foundation.org, akpm@google.com, linuxppc-dev@lists.ozlabs.org, minchan@kernel.org |
| Archive‑link: | |
Article |
Currently in the event of a stack overrun a call to schedule()
does not check for this type of corruption. This corruption is
often silent and can go unnoticed. However once the corrupted
region is examined at a later stage, the outcome is undefined
and often results in a sporadic page fault which cannot be
handled.
The first patch adds a canary to init_task's end of stack.
While the second patch provides a helper to determine the
integrity of the canary. The third checks for a stack
overrun and takes appropriate action since the damage
is already done, there is no point in continuing.
Changes since v1:
* Rebased against v3.17-rc4
* Add a canary to init_task - Oleg Nesterov
* Fix various code formatting issues - Peter Zijlstra
* Introduce Kconfig option - Peter Zijlstra
Aaron Tomlin (3):
init/main.c: Give init_task a canary
sched: Add helper for task stack page overrun checking
sched: BUG when stack end location is over written
arch/powerpc/mm/fault.c | 5 +----
arch/x86/mm/fault.c | 5 +----
include/linux/sched.h | 4 ++++
init/main.c | 1 +
kernel/fork.c | 12 +++++++++---
kernel/sched/core.c | 4 ++++
kernel/trace/trace_stack.c | 4 +---
lib/Kconfig.debug | 12 ++++++++++++
8 files changed, 33 insertions(+), 14 deletions(-)
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
