summaryrefslogtreecommitdiff
path: root/lib/list_debug.c
AgeCommit message (Collapse)Author
2018-10-04UPSTREAM: bug: switch data corruption check to __must_checkKees Cook
(cherry-picked from 85caa95b9f19bb3a26d7e025d1134760b69e0c40) The CHECK_DATA_CORRUPTION() macro was designed to have callers do something meaningful/protective on failure. However, using "return false" in the macro too strictly limits the design patterns of callers. Instead, let callers handle the logic test directly, but make sure that the result IS checked by forcing __must_check (which appears to not be able to be used directly on macro expressions). Change-Id: I635dc2f39959104ea8b475d2d5018af3502f33ba Link: http://lkml.kernel.org/r/20170206204547.GA125312@beast Signed-off-by: Kees Cook <keescook@chromium.org> Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
2018-10-04UPSTREAM: bug: Provide toggle for BUG on data corruptionKees Cook
(cherry-picked from de54ebbe26bb371a6f1fbc0593372232f04e3107) The kernel checks for cases of data structure corruption under some CONFIGs (e.g. CONFIG_DEBUG_LIST). When corruption is detected, some systems may want to BUG() immediately instead of letting the system run with known corruption. Usually these kinds of manipulation primitives can be used by security flaws to gain arbitrary memory write control. This provides a new config CONFIG_BUG_ON_DATA_CORRUPTION and a corresponding macro CHECK_DATA_CORRUPTION for handling these situations. Notably, even if not BUGing, the kernel should not continue processing the corrupted structure. This is inspired by similar hardening by Syed Rameez Mustafa in MSM kernels, and in PaX and Grsecurity, which is likely in response to earlier removal of the BUG calls in commit 924d9addb9b1 ("list debugging: use WARN() instead of BUG()"). Change-Id: I4cdfa9fbebe32a990a111d051e4ec4e421f77a09 Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: Rik van Riel <riel@redhat.com> Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
2018-10-04UPSTREAM: list: Split list_del() debug checking into separate functionKees Cook
(cherry-picked from 0cd340dcb05c4a43742fe156f36737bb2a321bfd) Similar to the list_add() debug consolidation, this commit consolidates the debug checking performed during CONFIG_DEBUG_LIST into a new __list_del_entry_valid() function, and stops list updates when corruption is found. Refactored from same hardening in PaX and Grsecurity. Change-Id: I9e3b8654ab25f3a196e3336fc4882b73010873e7 Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: Rik van Riel <riel@redhat.com> Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
2018-10-04UPSTREAM: rculist: Consolidate DEBUG_LIST for list_add_rcu()Kees Cook
(cherry-picked from 54acd4397d7e7a725c94101180cd9f38ef701acc) This commit consolidates the debug checking for list_add_rcu() into the new single __list_add_valid() debug function. Notably, this commit fixes the sanity check that was added in commit 17a801f4bfeb ("list_debug: WARN for adding something already in the list"), which wasn't checking RCU-protected lists. Change-Id: I1f7e169d4dc45bbc9938087a171c5df747344414 Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: Rik van Riel <riel@redhat.com> Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
2018-10-04BACKPORT: list: Split list_add() debug checking into separate functionKees Cook
(cherry-picked from d7c816733d501b59dbdc2483f2cc8e4431fd9160) Right now, __list_add() code is repeated either in list.h or in list_debug.c, but the only differences between the two versions are the debug checks. This commit therefore extracts these debug checks into a separate __list_add_valid() function and consolidates __list_add(). Additionally this new __list_add_valid() function 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. Change-Id: I9a9c9a58857cf837bec7abdb2ee4970cd1242a5e Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: Rik van Riel <riel@redhat.com> Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
2012-07-06rcu: Fix broken strings in RCU's source code.Paul E. McKenney
Although the C language allows you to break strings across lines, doing this makes it hard for people to find the Linux kernel code corresponding to a given console message. This commit therefore fixes broken strings throughout RCU's source code. Suggested-by: Josh Triplett <josh@joshtriplett.org> Suggested-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
2012-05-29list_debug: WARN for adding something already in the listChris Metcalf
We were bitten by this at one point and added an additional sanity test for DEBUG_LIST. You can't validly add a list_head to a list where either prev or next is the same as the thing you're adding. Signed-off-by: Chris Metcalf <cmetcalf@tilera.com> Cc: Andi Kleen <andi@firstfloor.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-04-24rcu: List-debug variants of rcu list routines.Dave Jones
* Make __list_add_rcu check the next->prev and prev->next pointers just like __list_add does. * Make list_del_rcu use __list_del_entry, which does the same checking at deletion time. Has been running for a week here without anything being tripped up, but it seems worth adding for completeness just in case something ever does corrupt those lists. Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
2012-03-24Merge tag 'module-for-3.4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux Pull cleanup of fs/ and lib/ users of module.h from Paul Gortmaker: "Fix up files in fs/ and lib/ dirs to only use module.h if they really need it. These are trivial in scope vs the work done previously. We now have things where any few remaining cleanups can be farmed out to arch or subsystem maintainers, and I have done so when possible. What is remaining here represents the bits that don't clearly lie within a single arch/subsystem boundary, like the fs dir and the lib dir. Some duplicate includes arising from overlapping fixes from independent subsystem maintainer submissions are also quashed." Fix up trivial conflicts due to clashes with other include file cleanups (including some due to the previous bug.h cleanup pull). * tag 'module-for-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux: lib: reduce the use of module.h wherever possible fs: reduce the use of module.h wherever possible includecheck: delete any duplicate instances of module.h
2012-03-07lib: reduce the use of module.h wherever possiblePaul Gortmaker
For files only using THIS_MODULE and/or EXPORT_SYMBOL, map them onto including export.h -- or if the file isn't even using those, then just delete the include. Fix up any implicit include dependencies that were being masked by module.h along the way. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-02-29bug.h: add include of it to various implicit C usersPaul Gortmaker
With bug.h currently living right in linux/kernel.h there are files that use BUG_ON and friends but are not including the header explicitly. Fix them up so we can remove the presence in kernel.h file. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-02-28lib: fix implicit users of kernel.h for TAINT_WARNPaul Gortmaker
A pending header cleanup will cause this to show up as: lib/average.c:38: error: 'TAINT_WARN' undeclared (first use in this function) lib/list_debug.c:24: error: 'TAINT_WARN' undeclared (first use in this function) and TAINT_WARN comes from include/linux/kernel.h file. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-02-18Expand CONFIG_DEBUG_LIST to several other list operationsLinus Torvalds
When list debugging is enabled, we aim to readably show list corruption errors, and the basic list_add/list_del operations end up having extra debugging code in them to do some basic validation of the list entries. However, "list_del_init()" and "list_move[_tail]()" ended up avoiding the debug code due to how they were written. This fixes that. So the _next_ time we have list_move() problems with stale list entries, we'll hopefully have an easier time finding them.. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-09list debugging: warn when deleting a deleted entryBaruch Siach
Use the magic LIST_POISON* values to detect an incorrect use of list_del on a deleted entry. This DEBUG_LIST specific warning is easier to understand than the generic Oops message caused by LIST_POISON dereference. Signed-off-by: Baruch Siach <baruch@tkos.co.il> Cc: Dave Jones <davej@codemonkey.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-07-25list debugging: use WARN() instead of BUG()Dave Jones
Arjan noted that the list_head debugging is BUG'ing when it detects corruption. By causing the box to panic immediately, we're possibly losing some bug reports. Changing this to a WARN() should mean we at the least start seeing reports collected at kerneloops.org Signed-off-by: Dave Jones <davej@redhat.com> Cc: Matthew Wilcox <matthew@wil.cx> Cc: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-07-25lists: remove a redundant conditional definition of list_add()Robert P. J. Day
Remove the conditional surrounding the definition of list_add() from list.h since, if you define CONFIG_DEBUG_LIST, the definition you will subsequently pick up from lib/list_debug.c will be absolutely identical, at which point you can remove that redundant definition from list_debug.c as well. Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca> Cc: Dave Jones <davej@codemonkey.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2006-12-07[PATCH] More list debugging contextDave Jones
Print the other (hopefully) known good pointer when list_head debugging too, which may yield additional clues. Also fix for 80-columns to win akpm brownie points. Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-01[PATCH] list_del-debug fixAndrew Morton
These two BUG_ON()s are redundant and undesired: we're checking for this condition further on in the function, only better. Cc: Dave Jones <davej@codemonkey.org.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-09-29[PATCH] list_del debug checkManfred Spraul
A list_del() debugging check. Has been in -mm for years. Dave moved list_del() out-of-line in the debug case, so this is now suitable for mainline. Cc: Dave Jones <davej@codemonkey.org.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-09-29[PATCH] Debug variants of linked list macrosDave Jones
Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>