- 06 3月, 2017 1 次提交
-
-
由 Al Viro 提交于
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
- 28 9月, 2016 1 次提交
-
-
由 Al Viro 提交于
externs and defines for stuff that is never used Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
- 14 9月, 2016 1 次提交
-
-
由 Al Viro 提交于
both for access_ok() failures and for faults halfway through Cc: stable@vger.kernel.org Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
- 10 9月, 2016 1 次提交
-
-
由 Al Viro 提交于
... in all cases, including the failing access_ok() Note that some architectures using asm-generic/uaccess.h have __copy_from_user() not zeroing the tail on failure halfway through. This variant works either way. Cc: stable@vger.kernel.org Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
- 31 8月, 2016 1 次提交
-
-
由 Josh Poimboeuf 提交于
There are three usercopy warnings which are currently being silenced for gcc 4.6 and newer: 1) "copy_from_user() buffer size is too small" compile warning/error This is a static warning which happens when object size and copy size are both const, and copy size > object size. I didn't see any false positives for this one. So the function warning attribute seems to be working fine here. Note this scenario is always a bug and so I think it should be changed to *always* be an error, regardless of CONFIG_DEBUG_STRICT_USER_COPY_CHECKS. 2) "copy_from_user() buffer size is not provably correct" compile warning This is another static warning which happens when I enable __compiletime_object_size() for new compilers (and CONFIG_DEBUG_STRICT_USER_COPY_CHECKS). It happens when object size is const, but copy size is *not*. In this case there's no way to compare the two at build time, so it gives the warning. (Note the warning is a byproduct of the fact that gcc has no way of knowing whether the overflow function will be called, so the call isn't dead code and the warning attribute is activated.) So this warning seems to only indicate "this is an unusual pattern, maybe you should check it out" rather than "this is a bug". I get 102(!) of these warnings with allyesconfig and the __compiletime_object_size() gcc check removed. I don't know if there are any real bugs hiding in there, but from looking at a small sample, I didn't see any. According to Kees, it does sometimes find real bugs. But the false positive rate seems high. 3) "Buffer overflow detected" runtime warning This is a runtime warning where object size is const, and copy size > object size. All three warnings (both static and runtime) were completely disabled for gcc 4.6 with the following commit: 2fb0815c ("gcc4: disable __compiletime_object_size for GCC 4.6+") That commit mistakenly assumed that the false positives were caused by a gcc bug in __compiletime_object_size(). But in fact, __compiletime_object_size() seems to be working fine. The false positives were instead triggered by #2 above. (Though I don't have an explanation for why the warnings supposedly only started showing up in gcc 4.6.) So remove warning #2 to get rid of all the false positives, and re-enable warnings #1 and #3 by reverting the above commit. Furthermore, since #1 is a real bug which is detected at compile time, upgrade it to always be an error. Having done all that, CONFIG_DEBUG_STRICT_USER_COPY_CHECKS is no longer needed. Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com> Cc: Kees Cook <keescook@chromium.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@kernel.org> Cc: "H . Peter Anvin" <hpa@zytor.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Brian Gerst <brgerst@gmail.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Byungchul Park <byungchul.park@lge.com> Cc: Nilay Vaish <nilayvaish@gmail.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 08 11月, 2015 1 次提交
-
-
由 Yoshinori Sato 提交于
Current implemantation ptr argument evaluate 2 times. It'll be an unexpected result. Changes v5: Remove unnecessary const. Changes v4: Temporary pointer type change to const void* Changes v3: Some build error fix. Changes v2: Argument x protect. Signed-off-by: NYoshinori Sato <ysato@users.sourceforge.jp>
-
- 02 1月, 2014 1 次提交
-
-
由 Geert Uytterhoeven 提交于
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 28 5月, 2013 1 次提交
-
-
由 Michael S. Tsirkin 提交于
The only reason uaccess routines might sleep is if they fault. Make this explicit. Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NPeter Zijlstra <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1369577426-26721-1-git-send-email-mst@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
- 11 2月, 2013 2 次提交
-
-
由 Vineet Gupta 提交于
As of now these default to calling the arch provided __copy_{to,from}_user() routines which being general purpose (w.r.t buffer alignment and lengths) would lead to alignment checks in generated code (for arches which don't support unaligned load/stores). Given that in this case we already know that data involved is "unit" sized and aligned, using the vanilla copy backend is a bit wasteful. This change thus allows arches to over-ride the aforementioned routines. Signed-off-by: NVineet Gupta <vgupta@synopsys.com> Acked-by: NArnd Bergmann <arnd@arndb.de>
-
由 Vineet Gupta 提交于
This is because mm_segment_t is exported by arch code, while seqment_eq assumes it will have .seg element. Acked-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
-
- 07 10月, 2011 1 次提交
-
-
由 Mark Salter 提交于
The existing __strnlen_user macro simply resolved to strnlen. However, the count returned by strnlen_user should include the NULL byte. This patch fixes the __strnlen_user macro to include the NULL byte in the count. Signed-off-by: NMark Salter <msalter@redhat.com> Acked-by: NArnd Bergmann <arnd@arndb.de>
-
- 17 3月, 2011 1 次提交
-
-
由 GuanXuetao 提交于
This patch changes the implementation of strnlen_user in include/asm-generic/uaccess.h. Originally, it calls strlen() function directly, which may not correctly handle the access of user space in most mmu-enabled architectures. New __strnlen_user is added for using as an architecture specific function. Signed-off-by: NGuan Xuetao <gxt@mprc.pku.edu.cn> Reviewed-by: NArnd Bergmann <arnd@arndb.de>
-
- 19 6月, 2009 2 次提交
-
-
由 Mike Frysinger 提交于
There's no reason that I can see to use the short __access_ok() form directly when the access_ok() is clearer in intent and for most people, expands to the same C code (i.e. always specify the first field -- access type). Not all no-mmu systems lack memory protection, so the read/write could feasibly be checked. Signed-off-by: NMike Frysinger <vapier@gentoo.org> Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
由 Mike Frysinger 提交于
The strnlen_user() function was missing a access_ok() check on the pointer given. We've had cases on Blackfin systems where test programs caused kernel crashes here because userspace passed up a NULL/-1 pointer and the kernel gladly attempted to run strlen() on it. Signed-off-by: NMike Frysinger <vapier@gentoo.org> Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
- 12 6月, 2009 2 次提交
-
-
由 Arnd Bergmann 提交于
Based on discussions with Michal Simek and code from m68knommu and h8300, this version of uaccess.h should be usable by most architectures, by overriding some parts of it. Simple NOMMU architectures can use it out of the box, but a minimal __access_ok() should be added there as well. Cc: Michal Simek <monstr@monstr.eu> Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
由 Arnd Bergmann 提交于
The current asm-generic/page.h only contains the get_order function, and asm-generic/uaccess.h only implements unaligned accesses. This renames the file to getorder.h and uaccess-unaligned.h to make room for new page.h and uaccess.h file that will be usable by all simple (e.g. nommu) architectures. Signed-off-by: NRemis Lima Baima <remis.developer@googlemail.com> Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-