- 06 Feb, 2017 40 commits
-
-
Andrey Ryabinin authored
commit 70d78fe7 upstream. It could be not possible to freeze coredumping task when it waits for 'core_state->startup' completion, because threads are frozen in get_signal() before they got a chance to complete 'core_state->startup'. Inability to freeze a task during suspend will cause suspend to fail. Also CRIU uses cgroup freezer during dump operation. So with an unfreezable task the CRIU dump will fail because it waits for a transition from 'FREEZING' to 'FROZEN' state which will never happen. Use freezer_do_not_count() to tell freezer to ignore coredumping task while it waits for core_state->startup completion. Link: http://lkml.kernel.org/r/1475225434-3753-1-git-send-email-aryabinin@virtuozzo.comSigned-off-by:
Andrey Ryabinin <aryabinin@virtuozzo.com> Acked-by:
Pavel Machek <pavel@ucw.cz> Acked-by:
Oleg Nesterov <oleg@redhat.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Tejun Heo <tj@kernel.org> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Michal Hocko <mhocko@kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Willy Tarreau <w@1wt.eu>
-
Jann Horn authored
commit dd111be6 upstream. When root activates a swap partition whose header has the wrong endianness, nr_badpages elements of badpages are swabbed before nr_badpages has been checked, leading to a buffer overrun of up to 8GB. This normally is not a security issue because it can only be exploited by root (more specifically, a process with CAP_SYS_ADMIN or the ability to modify a swap file/partition), and such a process can already e.g. modify swapped-out memory of any other userspace process on the system. Link: http://lkml.kernel.org/r/1477949533-2509-1-git-send-email-jann@thejh.netSigned-off-by:
Jann Horn <jann@thejh.net> Acked-by:
Kees Cook <keescook@chromium.org> Acked-by:
Jerome Marchand <jmarchan@redhat.com> Acked-by:
Johannes Weiner <hannes@cmpxchg.org> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Hugh Dickins <hughd@google.com> Signed-off-by:
-
Linus Torvalds authored
Not upstream as it is not needed there. So a patch something like this might be a safe way to fix the potential infoleak in older kernels. THIS IS UNTESTED. It's a very obvious patch, though, so if it compiles it probably works. It just initializes the output variable with 0 in the inline asm description, instead of doing it in the exception handler. It will generate slightly worse code (a few unnecessary ALU operations), but it doesn't have any interactions with the exception handler implementation. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Signed-off-by:
-
Al Viro authored
commit 7798bf21 upstream. On faulting sigreturn we do get SIGSEGV, all right, but anything we'd put into pt_regs could end up in the coredump. And since __copy_from_user() never zeroed on arc, we'd better bugger off on its failure without copying random uninitialized bits of kernel stack into pt_regs... Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Al Viro authored
commit 1ae2293d upstream. Signed-off-by:
-
Al Viro authored
commit e23d4159 upstream. Switching iov_iter fault-in to multipages variants has exposed an old bug in underlying fault_in_multipages_...(); they break if the range passed to them wraps around. Normally access_ok() done by callers will prevent such (and it's a guaranteed EFAULT - ERR_PTR() values fall into such a range and they should not point to any valid objects). However, on architectures where userland and kernel live in different MMU contexts (e.g. s390) access_ok() is a no-op and on those a range with a wraparound can reach fault_in_multipages_...(). Since any wraparound means EFAULT there, the fix is trivial - turn those while (uaddr <= end) ... into if (unlikely(uaddr > end)) return -EFAULT; do ... while (uaddr <= end); Reported-by:
Jan Stancek <jstancek@redhat.com> Tested-by:
-
Al Viro authored
commit a5e541f7 upstream. Signed-off-by:
-
Al Viro authored
commit 22426465 upstream. should clear on access_ok() failures. Also remove the useless range truncation logics. Signed-off-by:
-
Al Viro authored
commit 917400ce upstream. Acked-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Al Viro authored
commit ae7cc577 upstream. Signed-off-by:
-
Guenter Roeck authored
commit 8e4b7205 upstream. Since commit acb2505d ("openrisc: fix copy_from_user()"), copy_from_user() returns the number of bytes requested, not the number of bytes not copied. Cc: Al Viro <viro@zeniv.linux.org.uk> Fixes: acb2505d ("openrisc: fix copy_from_user()") Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Al Viro authored
commit acb2505d upstream. ... that should zero on faults. Also remove the <censored> helpful logics wrt range truncation copied from ppc32. Where it had ever been needed only in case of copy_from_user() *and* had not been merged into the mainline until a month after the need had disappeared. A decade before openrisc went into mainline, I might add... Signed-off-by:
-
Al Viro authored
commit aace880f upstream. Signed-off-by:
-
Al Viro authored
commit 8ae95ed4 upstream. Acked-by:
James Hogan <james.hogan@imgtec.com> Signed-off-by:
-
Al Viro authored
commit 2561d309 upstream. it should clear the destination even when access_ok() fails. Signed-off-by:
-
Al Viro authored
commit 2545e5da upstream. ... 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. Signed-off-by:
-
Al Viro authored
commit e69d7005 upstream. Signed-off-by:
-
Al Viro authored
commit f35c1e06 upstream. It's -EFAULT, not -1 (and contrary to the comment in there, __strnlen_user() can return 0 - on faults). Acked-by:
Richard Kuo <rkuo@codeaurora.org> Signed-off-by:
-
Al Viro authored
commit 6e050503 upstream. Signed-off-by:
-
Al Viro authored
commit b615e3c7 upstream. Signed-off-by:
-
Al Viro authored
commit 8f035983 upstream. Signed-off-by:
-
Al Viro authored
commit eb47e029 upstream. * copy_from_user() on access_ok() failure ought to zero the destination * none of those primitives should skip the access_ok() check in case of small constant size. Acked-by:
Jesper Nilsson <jesper.nilsson@axis.com> Signed-off-by:
-
Al Viro authored
commit 3b8767a8 upstream. It should check access_ok(). Otherwise a bunch of places turn into trivially exploitable rootholes. Signed-off-by:
-
Al Viro authored
commit 9ad18b75 upstream. both for access_ok() failures and for faults halfway through Signed-off-by:
-
Vineet Gupta authored
commit 05d9d0b9 upstream. Al reported potential issue with ARC get_user() as it wasn't clearing out destination pointer in case of fault due to bad address etc. Verified using following | { | u32 bogus1 = 0xdeadbeef; | u64 bogus2 = 0xdead; | int rc1, rc2; | | pr_info("Orig values %x %llx\n", bogus1, bogus2); | rc1 = get_user(bogus1, (u32 __user *)0x40000000); | rc2 = get_user(bogus2, (u64 __user *)0x50000000); | pr_info("access %d %d, new values %x %llx\n", | rc1, rc2, bogus1, bogus2); | } | [ARCLinux]# insmod /mnt/kernel-module/qtn.ko | Orig values deadbeef dead | access -14 -14, new values 0 0 Reported-by:
Vineet Gupta <vgupta@synopsys.com> Signed-off-by:
-
Al Viro authored
commit fd2d2b19 upstream. Signed-off-by:
-
Al Viro authored
commit c2f18fa4 upstream. * should zero on any failure * __get_user() should use __copy_from_user(), not copy_from_user() Signed-off-by:
-
Al Viro authored
commit c6852389 upstream. It could be done in exception-handling bits in __get_user_b() et.al., but the surgery involved would take more knowledge of sh64 details than I have or _want_ to have. Signed-off-by:
-
Al Viro authored
commit c90a3bc5 upstream. Signed-off-by:
-
Al Viro authored
commit 43403eab upstream. Signed-off-by:
-
Al Viro authored
commit d0cf3851 upstream. Signed-off-by:
-
Al Viro authored
commit e98b9e37 upstream. Signed-off-by:
-
John David Anglin authored
commit 6ed51832 upstream. We have one critical section in the syscall entry path in which we switch from the userspace stack to kernel stack. In the event of an external interrupt, the interrupt code distinguishes between those two states by analyzing the value of sr7. If sr7 is zero, it uses the kernel stack. Therefore it's important, that the value of sr7 is in sync with the currently enabled stack. This patch now disables interrupts while executing the critical section. This prevents the interrupt handler to possibly see an inconsistent state which in the worst case can lead to crashes. Interestingly, in the syscall exit path interrupts were already disabled in the critical section which switches back to the userspace stack. Signed-off-by:
John David Anglin <dave.anglin@bell.net> Signed-off-by:
Helge Deller <deller@gmx.de> Signed-off-by:
-
Stefan Haberland authored
commit 9ba333dc upstream. When a device is in a status where CIO has killed all I/O by itself the interrupt for a clear request may not contain an irb to determine the clear function. Instead it contains an error pointer -EIO. This was ignored by the DASD int_handler leading to a hanging device waiting for a clear interrupt. Handle -EIO error pointer correctly for requests that are clear pending and treat the clear as successful. Signed-off-by:
Stefan Haberland <sth@linux.vnet.ibm.com> Reviewed-by:
Sebastian Ott <sebott@linux.vnet.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Dan Carpenter authored
commit 55f1cf83 upstream. The pio_dev[] array has MAX_NR_PIO_DEVICES elements so the > should be >=. Fixes: 5f97f7f9 ('[PATCH] avr32 architecture') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Guenter Roeck authored
commit 65c0044c upstream. avr32 builds fail with: arch/avr32/kernel/built-in.o: In function `arch_ptrace': (.text+0x650): undefined reference to `___copy_from_user' arch/avr32/kernel/built-in.o:(___ksymtab+___copy_from_user+0x0): undefined reference to `___copy_from_user' kernel/built-in.o: In function `proc_doulongvec_ms_jiffies_minmax': (.text+0x5dd8): undefined reference to `___copy_from_user' kernel/built-in.o: In function `proc_dointvec_minmax_sysadmin': sysctl.c:(.text+0x6174): undefined reference to `___copy_from_user' kernel/built-in.o: In function `ptrace_has_cap': ptrace.c:(.text+0x69c0): undefined reference to `___copy_from_user' kernel/built-in.o:ptrace.c:(.text+0x6b90): more undefined references to `___copy_from_user' follow Fixes: 8630c322 ("avr32: fix copy_from_user()") Cc: Al Viro <viro@zeniv.linux.org.uk> Acked-by:
Havard Skinnemoen <hskinnemoen@gmail.com> Acked-by:
Hans-Christian Noren Egtvedt <egtvedt@samfundet.no> Signed-off-by:
-
Al Viro authored
commit 8630c322 upstream. really ugly, but apparently avr32 compilers turns access_ok() into something so bad that they want it in assembler. Left that way, zeroing added in inline wrapper. Signed-off-by:
-
Pan Xinhui authored
commit 11b7e154 upstream. When we merge two contiguous partitions whose signatures are marked NVRAM_SIG_FREE, We need update prev's length and checksum, then write it to nvram, not cur's. So lets fix this mistake now. Also use memset instead of strncpy to set the partition's name. It's more readable if we want to fill up with duplicate chars . Fixes: fa2b4e54 ("powerpc/nvram: Improve partition removal") Signed-off-by:
Pan Xinhui <xinhui.pan@linux.vnet.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Paul Mackerras authored
commit 1a34439e upstream. Debugging a data corruption issue with virtio-net/vhost-net led to the observation that __copy_tofrom_user was occasionally returning a value 16 larger than it should. Since the return value from __copy_tofrom_user is the number of bytes not copied, this means that __copy_tofrom_user can occasionally return a value larger than the number of bytes it was asked to copy. In turn this can cause higher-level copy functions such as copy_page_to_iter_iovec to corrupt memory by copying data into the wrong memory locations. It turns out that the failing case involves a fault on the store at label 79, and at that point the first unmodified byte of the destination is at R3 + 16. Consequently the exception handler for that store needs to add 16 to R3 before using it to work out how many bytes were not copied, but in this one case it was not adding the offset to R3. To fix it, this moves the label 179 to the point where we add 16 to R3. I have checked manually all the exception handlers for the loads and stores in this code and the rest of them are correct (it would be excellent to have an automated test of all the exception cases). This bug has been present since this code was initially committed in May 2002 to Linux version 2.5.20. Signed-off-by:
Paul Mackerras <paulus@ozlabs.org> Signed-off-by:
-
Gavin Shan authored
commit 5adaf862 upstream. This fixes the warnings reported from sparse: pci.c:312:33: warning: restricted __be64 degrades to integer pci.c:313:33: warning: restricted __be64 degrades to integer Fixes: cee72d5b ("powerpc/powernv: Display diag data on p7ioc EEH errors") Signed-off-by:
Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by:
-
