aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* i9300: disable samsung_extdisp driver and regenerate defconfigreplicant-6.0-alpha-0004Wolfgang Wiedmeyer2016-03-251-3/+1
| | | | | | | | | | | | | The samsung_extdisp driver for GT-I9500 was affected by CVE-2015-1800 and CVE-2015-1801. The Galaxy S3 uses an older version of this driver and is at least affected by CVE-2015-1801. Newer kernel versions for the GT-I9500 had the driver completely removed. I also found no indication that the driver is actually needed for the S3, so let's disable it. vulnerability disclosure and further information: http://blog.quarkslab.com/kernel-vulnerabilities-in-the-samsung-s4.html Signed-off-by: Wolfgang Wiedmeyer <wolfgit@wiedmeyer.de>
* pipe: iovec: Fix memory corruption when retrying atomic copy as non-atomicBen Hutchings2016-03-191-23/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | pipe_iov_copy_{from,to}_user() may be tried twice with the same iovec, the first time atomically and the second time not. The second attempt needs to continue from the iovec position, pipe buffer offset and remaining length where the first attempt failed, but currently the pipe buffer offset and remaining length are reset. This will corrupt the piped data (possibly also leading to an information leak between processes) and may also corrupt kernel memory. This was fixed upstream by commits f0d1bec9d58d ("new helper: copy_page_from_iter()") and 637b58c2887e ("switch pipe_read() to copy_page_to_iter()"), but those aren't suitable for stable. This fix for older kernel versions was made by Seth Jennings for RHEL and I have extracted it from their update. CVE-2015-1805 Bug: 27275324 Change-Id: I459adb9076fcd50ff1f1c557089c4e421b036ec4 References: https://bugzilla.redhat.com/show_bug.cgi?id=1202855 Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 85c34d007116f8a8aafb173966a605fb03532f45)
* Input: add infrastructure for selecting clockid for event time stampsJohn Stultz2016-03-183-4/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | As noted by Arve and others, since wall time can jump backwards, it is difficult to use for input because one cannot determine if one event occurred before another or for how long a key was pressed. However, the timestamp field is part of the kernel ABI, and cannot be changed without possibly breaking existing users. This patch adds a new IOCTL that allows a clockid to be set in the evdev_client struct that will specify which time base to use for event timestamps (ie: CLOCK_MONOTONIC instead of CLOCK_REALTIME). For now we only support CLOCK_MONOTONIC and CLOCK_REALTIME, but in the future we could support other clockids if appropriate. The default remains CLOCK_REALTIME, so we don't change the ABI. Signed-off-by: John Stultz <john.stultz@linaro.org> Reviewed-by: Daniel Kurtz <djkurtz@google.com> Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Conflicts: include/linux/input.h Change-Id: I7b9b442dcd7930a1e72c688327e6fb7275107128
* input: Don't use monotonic time for event time stamps.Ziyan2016-03-181-4/+1
| | | | Change-Id: Id0a5c96eb8a7d1d8e08bd3b7a4ac50cdc9c73f39
* fuse: break infinite loop in fuse_fill_write_pages()Roman Gushchin2016-03-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I got a report about unkillable task eating CPU. Further investigation shows, that the problem is in the fuse_fill_write_pages() function. If iov's first segment has zero length, we get an infinite loop, because we never reach iov_iter_advance() call. Fix this by calling iov_iter_advance() before repeating an attempt to copy data from userspace. A similar problem is described in 124d3b7041f ("fix writev regression: pan hanging unkillable and un-straceable"). If zero-length segmend is followed by segment with invalid address, iov_iter_fault_in_readable() checks only first segment (zero-length), iov_iter_copy_from_user_atomic() skips it, fails at second and returns zero -> goto again without skipping zero-length segment. Patch calls iov_iter_advance() before goto again: we'll skip zero-length segment at second iteraction and iov_iter_fault_in_readable() will detect invalid address. Special thanks to Konstantin Khlebnikov, who helped a lot with the commit description. Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Maxim Patlasov <mpatlasov@parallels.com> Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru> Signed-off-by: Roman Gushchin <klamm@yandex-team.ru> Signed-off-by: Miklos Szeredi <miklos@szeredi.hu> Fixes: ea9b9907b82a ("fuse: implement perform_write") Cc: <stable@vger.kernel.org> Conflicts: fs/fuse/file.c Change-Id: Id37193373294dd43191469389cfe68ca1736a54b
* Revert "udp: remove redundant variable"David S. Miller2016-03-182-14/+16
| | | | | | | | | | | | | This reverts commit 81d54ec8479a2c695760da81f05b5a9fb2dbe40a. If we take the "try_again" goto, due to a checksum error, the 'len' has already been truncated. So we won't compute the same values as the original code did. Change-Id: I0503e45682377965571c4544385811765ef2e2bb Reported-by: paul bilke <fsmail@conspiracy.net> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit 7c3b1de9c0ba32bd33ac15c62e8b8a0548641c6b)
* Staging: android: binder: Add some tracepointsArve Hjønnevåg2016-03-183-19/+399
| | | | | | | | | | | | | | Add tracepoints: - ioctl entry and exit - Main binder lock: lock, locked and unlock - Command and return buffer opcodes - Transaction: create and receive - Transaction buffer: create and free - Object and file descriptor transfer - binder_update_page_range Change-Id: Ib09ae78b0b8b75062325318e2307afd71b7c4458 Signed-off-by: Arve Hjønnevåg <arve@android.com>
* vfs: more mnt_parent cleanupsAl Viro2016-03-184-55/+29
| | | | | | | | | | | | | | | | | | | | | a) mount --move is checking that ->mnt_parent is non-NULL before looking if that parent happens to be shared; ->mnt_parent is never NULL and it's not even an misspelled !mnt_has_parent() b) pivot_root open-codes is_path_reachable(), poorly. c) so does path_is_under(), while we are at it. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> (backported from commit afac7cba7ed31968a95e181dc25e204e45009ea8) CVE-2014-7970 BugLink: http://bugs.launchpad.net/bugs/1383356 Signed-off-by: Luis Henriques <luis.henriques@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Andy Whitcroft <apw@canonical.com> Change-Id: I6b2297f46388f135c1b760a37d45efc0e33542db
* vfs: new internal helper: mnt_has_parent(mnt)Al Viro2016-03-185-12/+18
| | | | | | | | | | | | | | | | | | | | | vfsmounts have ->mnt_parent pointing either to a different vfsmount or to itself; it's never NULL and termination condition in loops traversing the tree towards root is mnt == mnt->mnt_parent. At least one place (see the next patch) is confused about what's going on; let's add an explicit helper checking it right way and use it in all places where we need it. Not that there had been too many, but... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> (cherry picked from commit b2dba1af3c4157040303a76d25216b1713d333d0) CVE-2014-7970 BugLink: http://bugs.launchpad.net/bugs/1383356 Signed-off-by: Luis Henriques <luis.henriques@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Andy Whitcroft <apw@canonical.com> Change-Id: Iaa5ab510804f3b17fe71197b8919d663a416bf05
* KEYS: Fix handling of stored error in a negatively instantiated user keyDavid Howells2016-03-183-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a user key gets negatively instantiated, an error code is cached in the payload area. A negatively instantiated key may be then be positively instantiated by updating it with valid data. However, the ->update key type method must be aware that the error code may be there. The following may be used to trigger the bug in the user key type: keyctl request2 user user "" @u keyctl add user user "a" @u which manifests itself as: BUG: unable to handle kernel paging request at 00000000ffffff8a IP: [<ffffffff810a376f>] __call_rcu.constprop.76+0x1f/0x280 kernel/rcu/tree.c:3046 PGD 7cc30067 PUD 0 Oops: 0002 [#1] SMP Modules linked in: CPU: 3 PID: 2644 Comm: a.out Not tainted 4.3.0+ #49 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 task: ffff88003ddea700 ti: ffff88003dd88000 task.ti: ffff88003dd88000 RIP: 0010:[<ffffffff810a376f>] [<ffffffff810a376f>] __call_rcu.constprop.76+0x1f/0x280 [<ffffffff810a376f>] __call_rcu.constprop.76+0x1f/0x280 kernel/rcu/tree.c:3046 RSP: 0018:ffff88003dd8bdb0 EFLAGS: 00010246 RAX: 00000000ffffff82 RBX: 0000000000000000 RCX: 0000000000000001 RDX: ffffffff81e3fe40 RSI: 0000000000000000 RDI: 00000000ffffff82 RBP: ffff88003dd8bde0 R08: ffff88007d2d2da0 R09: 0000000000000000 R10: 0000000000000000 R11: ffff88003e8073c0 R12: 00000000ffffff82 R13: ffff88003dd8be68 R14: ffff88007d027600 R15: ffff88003ddea700 FS: 0000000000b92880(0063) GS:ffff88007fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00000000ffffff8a CR3: 000000007cc5f000 CR4: 00000000000006e0 Stack: ffff88003dd8bdf0 ffffffff81160a8a 0000000000000000 00000000ffffff82 ffff88003dd8be68 ffff88007d027600 ffff88003dd8bdf0 ffffffff810a39e5 ffff88003dd8be20 ffffffff812a31ab ffff88007d027600 ffff88007d027620 Call Trace: [<ffffffff810a39e5>] kfree_call_rcu+0x15/0x20 kernel/rcu/tree.c:3136 [<ffffffff812a31ab>] user_update+0x8b/0xb0 security/keys/user_defined.c:129 [< inline >] __key_update security/keys/key.c:730 [<ffffffff8129e5c1>] key_create_or_update+0x291/0x440 security/keys/key.c:908 [< inline >] SYSC_add_key security/keys/keyctl.c:125 [<ffffffff8129fc21>] SyS_add_key+0x101/0x1e0 security/keys/keyctl.c:60 [<ffffffff8185f617>] entry_SYSCALL_64_fastpath+0x12/0x6a arch/x86/entry/entry_64.S:185 Note the error code (-ENOKEY) in EDX. A similar bug can be tripped by: keyctl request2 trusted user "" @u keyctl add trusted user "a" @u This should also affect encrypted keys - but that has to be correctly parameterised or it will fail with EINVAL before getting to the bit that will crashes. Change-Id: I171d566f431c56208e1fe279f466d2d399a9ac7c Reported-by: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Mimi Zohar <zohar@linux.vnet.ibm.com> Signed-off-by: James Morris <james.l.morris@oracle.com>
* md: use kzalloc() when bitmap is disabledBenjamin Randazzo2016-03-181-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit b6878d9e03043695dbf3fa1caa6dfc09db225b16 upstream. In drivers/md/md.c get_bitmap_file() uses kmalloc() for creating a mdu_bitmap_file_t called "file". 5769 file = kmalloc(sizeof(*file), GFP_NOIO); 5770 if (!file) 5771 return -ENOMEM; This structure is copied to user space at the end of the function. 5786 if (err == 0 && 5787 copy_to_user(arg, file, sizeof(*file))) 5788 err = -EFAULT But if bitmap is disabled only the first byte of "file" is initialized with zero, so it's possible to read some bytes (up to 4095) of kernel space memory from user space. This is an information leak. 5775 /* bitmap disabled, zero the first byte and copy out */ 5776 if (!mddev->bitmap_info.file) 5777 file->pathname[0] = '\0'; Change-Id: I7cd2a3c7fad2e2cb9edb8b4eff2af8a3a8f40149 Signed-off-by: Benjamin Randazzo <benjamin@randazzo.fr> Signed-off-by: NeilBrown <neilb@suse.com> [lizf: Backported to 3.4: fix both branches] Signed-off-by: Zefan Li <lizefan@huawei.com>
* net: add length argument to skb_copy_and_csum_datagram_iovecSabrina Dubroca2016-03-187-7/+14
| | | | | | | | | | | | | | | | | | Without this length argument, we can read past the end of the iovec in memcpy_toiovec because we have no way of knowing the total length of the iovec's buffers. This is needed for stable kernels where 89c22d8c3b27 ("net: Fix skb csum races when peeking") has been backported but that don't have the ioviter conversion, which is almost all the stable trees <= 3.18. This also fixes a kernel crash for NFS servers when the client uses -onfsvers=3,proto=udp to mount the export. Change-Id: I1865e3d7a1faee42a5008a9ad58c4d3323ea4bab Signed-off-by: Sabrina Dubroca <sd@queasysnail.net> Reviewed-by: Hannes Frederic Sowa <hannes@stressinduktion.org> (cherry picked from commit c91234366e4cfd4f70c73e7d79ede92a6e462a88)
* android: drivers: workaround debugfs race in binderRiley Andrews2016-03-181-3/+15
| | | | | | | | | | | | | If a /d/binder/proc/[pid] entry is kept open after linux has torn down the associated process, binder_proc_show can deference an invalid binder_proc that has been stashed in the debugfs inode. Validate that the binder_proc ptr passed into binder_proc_show has not been freed by looking for it within the global process list whilst the global lock is held. If the ptr is not valid, print nothing. Bug 19587483 Change-Id: I4abc6443d96cca6500608976cded5ff3d1697d33 Signed-off-by: Riley Andrews <riandrews@android.com>
* fs: take i_mutex during prepare_binprm for set[ug]id executablesJann Horn2016-03-181-25/+40
| | | | | | | | | | | | | | | | This prevents a race between chown() and execve(), where chowning a setuid-user binary to root would momentarily make the binary setuid root. This patch was mostly written by Linus Torvalds. Signed-off-by: Jann Horn <jann@thejh.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Conflicts: fs/exec.c Change-Id: Iecebf23d07e299689e4ba4fd74ea8821ef96e72b
* mm: Fix NULL pointer dereference in madvise(MADV_WILLNEED) supportKirill A. Shutemov2016-03-181-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Sasha Levin found a NULL pointer dereference that is due to a missing page table lock, which in turn is due to the pmd entry in question being a transparent huge-table entry. The code - introduced in commit 1998cc048901 ("mm: make madvise(MADV_WILLNEED) support swap file prefetch") - correctly checks for this situation using pmd_none_or_trans_huge_or_clear_bad(), but it turns out that that function doesn't work correctly. pmd_none_or_trans_huge_or_clear_bad() expected that pmd_bad() would trigger if the transparent hugepage bit was set, but it doesn't do that if pmd_numa() is also set. Note that the NUMA bit only gets set on real NUMA machines, so people trying to reproduce this on most normal development systems would never actually trigger this. Fix it by removing the very subtle (and subtly incorrect) expectation, and instead just checking pmd_trans_huge() explicitly. Reported-by: Sasha Levin <sasha.levin@oracle.com> Acked-by: Andrea Arcangeli <aarcange@redhat.com> [ Additionally remove the now stale test for pmd_trans_huge() inside the pmd_bad() case - Linus ] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Change-Id: I3f3763f236ef102de735297cd175cf514d40d28f
* vfs: read file_handle only once in handle_to_pathSasha Levin2016-03-181-2/+3
| | | | | | | | | | | | | | | We used to read file_handle twice. Once to get the amount of extra bytes, and once to fetch the entire structure. This may be problematic since we do size verifications only after the first read, so if the number of extra bytes changes in userspace between the first and second calls, we'll have an incoherent view of file_handle. Instead, read the constant size once, and copy that over to the final structure without having to re-read it again. Change-Id: Ib05e5129629e27d5a05953098c5bc470fae40d2a Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
* mnt: Prevent pivot_root from creating a loop in the mount treeEric W. Biederman2016-03-181-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Andy Lutomirski recently demonstrated that when chroot is used to set the root path below the path for the new ``root'' passed to pivot_root the pivot_root system call succeeds and leaks mounts. In examining the code I see that starting with a new root that is below the current root in the mount tree will result in a loop in the mount tree after the mounts are detached and then reattached to one another. Resulting in all kinds of ugliness including a leak of that mounts involved in the leak of the mount loop. Prevent this problem by ensuring that the new mount is reachable from the current root of the mount tree. [Added stable cc. Fixes CVE-2014-7970. --Andy] Cc: stable@vger.kernel.org Reported-by: Andy Lutomirski <luto@amacapital.net> Reviewed-by: Andy Lutomirski <luto@amacapital.net> Link: http://lkml.kernel.org/r/87bnpmihks.fsf@x220.int.ebiederm.org Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Andy Lutomirski <luto@amacapital.net> (backported from commit 0d0826019e529f21c84687521d03f60cd241ca7d) CVE-2014-7970 BugLink: http://bugs.launchpad.net/bugs/1383356 Signed-off-by: Luis Henriques <luis.henriques@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Andy Whitcroft <apw@canonical.com> Change-Id: I0fe1d090eeb4765cc49401784e44a430f9585498
* mnt: Only change user settable mount flags in remountEric W. Biederman2016-03-182-2/+4
| | | | | | | | | | | | | | | | | | | | | commit a6138db815df5ee542d848318e5dae681590fccd upstream. Kenton Varda <kenton@sandstorm.io> discovered that by remounting a read-only bind mount read-only in a user namespace the MNT_LOCK_READONLY bit would be cleared, allowing an unprivileged user to the remount a read-only mount read-write. Correct this by replacing the mask of mount flags to preserve with a mask of mount flags that may be changed, and preserve all others. This ensures that any future bugs with this mask and remount will fail in an easy to detect way where new mount flags simply won't change. Change-Id: I8ab8bda03a14b9b43e78f1dc6c818bbec048e986 Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Francis Moreau <francis.moro@gmail.com> Signed-off-by: Zefan Li <lizefan@huawei.com>
* eCryptfs: Remove buggy and unnecessary write in file name decode routineMichael Halcrow2016-03-181-1/+0
| | | | | | | | | | | | | | Dmitry Chernenkov used KASAN to discover that eCryptfs writes past the end of the allocated buffer during encrypted filename decoding. This fix corrects the issue by getting rid of the unnecessary 0 write when the current bit offset is 2. Change-Id: Id8e04a580e550495c46cd36fec430a1ec4342940 Signed-off-by: Michael Halcrow <mhalcrow@google.com> Reported-by: Dmitry Chernenkov <dmitryc@google.com> Suggested-by: Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org # v2.6.29+: 51ca58d eCryptfs: Filename Encryption: Encoding and encryption functions Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
* KEYS: close race between key lookup and freeingSasha Levin2016-03-181-2/+2
| | | | | | | | | | | | | | | | | When a key is being garbage collected, it's key->user would get put before the ->destroy() callback is called, where the key is removed from it's respective tracking structures. This leaves a key hanging in a semi-invalid state which leaves a window open for a different task to try an access key->user. An example is find_keyring_by_name() which would dereference key->user for a key that is in the process of being garbage collected (where key->user was freed but ->destroy() wasn't called yet - so it's still present in the linked list). This would cause either a panic, or corrupt memory. Change-Id: I7856b7012d1bb668b15977ed16a4ee5f9c2882de Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
* net/l2tp: don't fall back on UDP [get|set]sockoptSasha Levin2016-03-181-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | The l2tp [get|set]sockopt() code has fallen back to the UDP functions for socket option levels != SOL_PPPOL2TP since day one, but that has never actually worked, since the l2tp socket isn't an inet socket. As David Miller points out: "If we wanted this to work, it'd have to look up the tunnel and then use tunnel->sk, but I wonder how useful that would be" Since this can never have worked so nobody could possibly have depended on that functionality, just remove the broken code and return -EINVAL. Change-Id: I5fc9d8033eb368e72436ec7682adaa1ff387615a Reported-by: Sasha Levin <sasha.levin@oracle.com> Acked-by: James Chapman <jchapman@katalix.com> Acked-by: David Miller <davem@davemloft.net> Cc: Phil Turnbull <phil.turnbull@oracle.com> Cc: Vegard Nossum <vegard.nossum@oracle.com> Cc: Willy Tarreau <w@1wt.eu> Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* tracing/syscalls: Ignore numbers outside NR_syscalls' rangeRabin Vincent2016-03-181-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ARM has some private syscalls (for example, set_tls(2)) which lie outside the range of NR_syscalls. If any of these are called while syscall tracing is being performed, out-of-bounds array access will occur in the ftrace and perf sys_{enter,exit} handlers. # trace-cmd record -e raw_syscalls:* true && trace-cmd report ... true-653 [000] 384.675777: sys_enter: NR 192 (0, 1000, 3, 4000022, ffffffff, 0) true-653 [000] 384.675812: sys_exit: NR 192 = 1995915264 true-653 [000] 384.675971: sys_enter: NR 983045 (76f74480, 76f74000, 76f74b28, 76f74480, 76f76f74, 1) true-653 [000] 384.675988: sys_exit: NR 983045 = 0 ... # trace-cmd record -e syscalls:* true [ 17.289329] Unable to handle kernel paging request at virtual address aaaaaace [ 17.289590] pgd = 9e71c000 [ 17.289696] [aaaaaace] *pgd=00000000 [ 17.289985] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 17.290169] Modules linked in: [ 17.290391] CPU: 0 PID: 704 Comm: true Not tainted 3.18.0-rc2+ #21 [ 17.290585] task: 9f4dab00 ti: 9e710000 task.ti: 9e710000 [ 17.290747] PC is at ftrace_syscall_enter+0x48/0x1f8 [ 17.290866] LR is at syscall_trace_enter+0x124/0x184 Fix this by ignoring out-of-NR_syscalls-bounds syscall numbers. Commit cd0980fc8add "tracing: Check invalid syscall nr while tracing syscalls" added the check for less than zero, but it should have also checked for greater than NR_syscalls. Link: http://lkml.kernel.org/p/1414620418-29472-1-git-send-email-rabin@rab.in Fixes: cd0980fc8add "tracing: Check invalid syscall nr while tracing syscalls" Cc: stable@vger.kernel.org # 2.6.33+ Signed-off-by: Rabin Vincent <rabin@rab.in> Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Conflicts: kernel/trace/trace_syscalls.c Change-Id: I512142f8f1e1b2a8dc063209666dbce9737377e7
* tracing/syscalls: Fix perf syscall tracing when syscall_nr == -1Will Deacon2016-03-181-0/+4
| | | | | | | | | | | | | | | | | syscall_get_nr can return -1 in the case that the task is not executing a system call. This patch fixes perf_syscall_{enter,exit} to check that the syscall number is valid before using it as an index into a bitmap. Link: http://lkml.kernel.org/r/1345137254-7377-1-git-send-email-will.deacon@arm.com Change-Id: Iedc719957e184c6572b3ad94e241ae2a97a0b533 Cc: Jason Baron <jbaron@redhat.com> Cc: Wade Farnsworth <wade_farnsworth@mentor.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
* ext4: make orphan functions be no-op in no-journal modeAnatol Pomozov2016-03-181-4/+3
| | | | | | | | | | | | | | | Instead of checking whether the handle is valid, we check if journal is enabled. This avoids taking the s_orphan_lock mutex in all cases when there is no journal in use, including the error paths where ext4_orphan_del() is called with a handle set to NULL. Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Conflicts: fs/ext4/namei.c Change-Id: I734ccb8069fceb12b864e7b9dceb37e27ab94c61
* __ptrace_may_access() should not deny sub-threadsMark Grondona2016-03-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | commit 73af963f9f3036dffed55c3a2898598186db1045 upstream. __ptrace_may_access() checks get_dumpable/ptrace_has_cap/etc if task != current, this can can lead to surprising results. For example, a sub-thread can't readlink("/proc/self/exe") if the executable is not readable. setup_new_exec()->would_dump() notices that inode_permission(MAY_READ) fails and then it does set_dumpable(suid_dumpable). After that get_dumpable() fails. (It is not clear why proc_pid_readlink() checks get_dumpable(), perhaps we could add PTRACE_MODE_NODUMPABLE) Change __ptrace_may_access() to use same_thread_group() instead of "task == current". Any security check is pointless when the tasks share the same ->mm. Change-Id: Ib6ca927a1eb0637df8030aabcb3129d5be343512 Signed-off-by: Mark Grondona <mgrondona@llnl.gov> Signed-off-by: Ben Woodard <woodard@redhat.com> Signed-off-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* mm: reorder can_do_mlock to fix audit denialJeff Vander Stoep2016-03-181-2/+2
| | | | | | | | | | | | | | | | | | | | | A userspace call to mmap(MAP_LOCKED) may result in the successful locking of memory while also producing a confusing audit log denial. can_do_mlock checks capable and rlimit. If either of these return positive can_do_mlock returns true. The capable check leads to an LSM hook used by apparmour and selinux which produce the audit denial. Reordering so rlimit is checked first eliminates the denial on success, only recording a denial when the lock is unsuccessful as a result of the denial. Change-Id: I8d300365c8f85b002d6c5375a22abfb1b7579d20 Signed-off-by: Jeff Vander Stoep <jeffv@google.com> Acked-by: Nick Kralevich <nnk@google.com> Cc: Jeff Vander Stoep <jeffv@google.com> Cc: Sasha Levin <sasha.levin@oracle.com> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> Cc: Rik van Riel <riel@redhat.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Paul Cassella <cassella@cray.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
* tty: Fix unsafe ldisc reference via ioctl(TIOCGETD)Peter Hurley2016-03-181-1/+23
| | | | | | | | | | | | | | | | | | | ioctl(TIOCGETD) retrieves the line discipline id directly from the ldisc because the line discipline id (c_line) in termios is untrustworthy; userspace may have set termios via ioctl(TCSETS*) without actually changing the line discipline via ioctl(TIOCSETD). However, directly accessing the current ldisc via tty->ldisc is unsafe; the ldisc ptr dereferenced may be stale if the line discipline is changing via ioctl(TIOCSETD) or hangup. Wait for the line discipline reference (just like read() or write()) to retrieve the "current" line discipline id. Change-Id: I7dae813721d4631d84a7d48b7b908e3bc40617cb Cc: <stable@vger.kernel.org> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* net: wireless: bcmdhd: check packet length for event messagesPatrick Tjin2016-03-183-5/+15
| | | | | | | | | | | Check the datalen field is less than the size of packet received from the network. BUG=25306181 BUG=25668859 Signed-off-by: Patrick Tjin <pattjin@google.com> Change-Id: I3b021d88a95bd7d4e6e0d745d2527d73487bcadc
* net: wireless: bcmdhd: Add checks for stack buffer overflowsdataanddreams2016-03-181-5/+0
| | | | | | | | | | These two checks prevent exploitable buffer overflows in two scenarios. 1. Long WPS_ID_DEVICE_NAME in WPS info elements 2. Invalid SSID determined in certain scan results Bug: 25661991 Change-Id: I356c71b3ccda765b03a1a380c39e199c3c3e3261 Signed-off-by: Yuan Lin <yualin@google.com>
* bcmdhd: Add checks for stack buffer overflowsdataanddreams2016-03-181-2/+7
| | | | | | | | | These two checks prevent exploitable buffer overflows in two scenarios. 1. Long WPS_ID_DEVICE_NAME in WPS info elements 2. Invalid SSID determined in certain scan results Bug: 25661991 Change-Id: Ie2f99897df2e4ce9fabcc03bb6091796777f95fa
* BACKPORT: pagemap: do not leak physical addresses to non-privileged userspaceKirill A. Shutemov2016-03-181-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | (cherry pick from commit ab676b7d6fbf4b294bf198fb27ade5b0e865c7ce) As pointed by recent post[1] on exploiting DRAM physical imperfection, /proc/PID/pagemap exposes sensitive information which can be used to do attacks. This disallows anybody without CAP_SYS_ADMIN to read the pagemap. [1] http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html [ Eventually we might want to do anything more finegrained, but for now this is the simple model. - Linus ] Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Acked-by: Konstantin Khlebnikov <khlebnikov@openvz.org> Acked-by: Andy Lutomirski <luto@amacapital.net> Cc: Pavel Emelyanov <xemul@parallels.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Mark Seaborn <mseaborn@chromium.org> Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Mark Salyzyn <salyzyn@google.com> Bug: 26038811 Change-Id: Icd68075a32ef6c9be1ae00ae9cf5a68bbe7f4e4f
* include/linux/poison.h: fix LIST_POISON{1,2} offsetVasily Kulikov2016-03-181-2/+2
| | | | | | | | | | | | | | | | | | | | | Poison pointer values should be small enough to find a room in non-mmap'able/hardly-mmap'able space. E.g. on x86 "poison pointer space" is located starting from 0x0. Given unprivileged users cannot mmap anything below mmap_min_addr, it should be safe to use poison pointers lower than mmap_min_addr. The current poison pointer values of LIST_POISON{1,2} might be too big for mmap_min_addr values equal or less than 1 MB (common case, e.g. Ubuntu uses only 0x10000). There is little point to use such a big value given the "poison pointer space" below 1 MB is not yet exhausted. Changing it to a smaller value solves the problem for small mmap_min_addr setups. The values are suggested by Solar Designer: http://www.openwall.com/lists/oss-security/2015/05/02/6 Bug: 26186802 Change-Id: I2663f4e4d8725547c90ea14e082f10ae0cf80679 Signed-off-by: Yuan Lin <yualin@google.com>
* i9300: ZRAM_FOR_ANDROID=ySimon Shields2016-03-181-1/+1
| | | | | | derp Change-Id: I565a4467ae321359e5b1ba38741cf109a45f0f60
* KEYS: Fix race between read and revokeDavid Howells2016-03-181-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes CVE-2015-7550. There's a race between keyctl_read() and keyctl_revoke(). If the revoke happens between keyctl_read() checking the validity of a key and the key's semaphore being taken, then the key type read method will see a revoked key. This causes a problem for the user-defined key type because it assumes in its read method that there will always be a payload in a non-revoked key and doesn't check for a NULL pointer. Fix this by making keyctl_read() check the validity of a key after taking semaphore instead of before. I think the bug was introduced with the original keyrings code. This was discovered by a multithreaded test program generated by syzkaller (http://github.com/google/syzkaller). Here's a cleaned up version: #include <sys/types.h> #include <keyutils.h> #include <pthread.h> void *thr0(void *arg) { key_serial_t key = (unsigned long)arg; keyctl_revoke(key); return 0; } void *thr1(void *arg) { key_serial_t key = (unsigned long)arg; char buffer[16]; keyctl_read(key, buffer, 16); return 0; } int main() { key_serial_t key = add_key("user", "%", "foo", 3, KEY_SPEC_USER_KEYRING); pthread_t th[5]; pthread_create(&th[0], 0, thr0, (void *)(unsigned long)key); pthread_create(&th[1], 0, thr1, (void *)(unsigned long)key); pthread_create(&th[2], 0, thr0, (void *)(unsigned long)key); pthread_create(&th[3], 0, thr1, (void *)(unsigned long)key); pthread_join(th[0], 0); pthread_join(th[1], 0); pthread_join(th[2], 0); pthread_join(th[3], 0); return 0; } Build as: cc -o keyctl-race keyctl-race.c -lkeyutils -lpthread Run as: while keyctl-race; do :; done as it may need several iterations to crash the kernel. The crash can be summarised as: BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 IP: [<ffffffff81279b08>] user_read+0x56/0xa3 ... Call Trace: [<ffffffff81276aa9>] keyctl_read_key+0xb6/0xd7 [<ffffffff81277815>] SyS_keyctl+0x83/0xe0 [<ffffffff815dbb97>] entry_SYSCALL_64_fastpath+0x12/0x6f Change-Id: Id6e3b200377ca71c1dd4c0679de33b7165eb2c56 Reported-by: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: David Howells <dhowells@redhat.com> Tested-by: Dmitry Vyukov <dvyukov@google.com> Cc: stable@vger.kernel.org Signed-off-by: James Morris <james.l.morris@oracle.com>
* Revert "i9300: disable CMA for MFC"Simon Shields2016-03-181-1/+1
| | | | | | | | * this actually makes everything worse This reverts commit 1765c98fb7b0e24527baa3dbaf1fa4cdf5905232. Change-Id: Idc4d0d888cf29da191bf4b8423a45c1fda81f7b0
* crypto: testmgr - add empty test vectors for null ciphersJussi Kivilinna2016-03-181-0/+9
| | | | | | | | | | | | Without these, kernel log shows: [ 5.984881] alg: No test for cipher_null (cipher_null-generic) [ 5.985096] alg: No test for ecb(cipher_null) (ecb-cipher_null) [ 5.985170] alg: No test for compress_null (compress_null-generic) [ 5.985297] alg: No test for digest_null (digest_null-generic) Change-Id: I78448a5a39617212489aa14227569a2254811e14 Signed-off-by: Jussi Kivilinna <jussi.kivilinna@iki.fi> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* i9300: disable CMA for MFCSimon Shields2016-03-181-1/+1
| | | | Change-Id: Ic5e9ac846259583f5e6be540b760d97b8d214709
* i9300: enable pegasusq boostingSimon Shields2016-03-181-0/+1
| | | | Change-Id: Ie8ad0c5aa13d8af306c4d77a49f85c786b5454e5
* i9300: enable lsm330dlc input interfaceSimon Shields2016-03-181-0/+1
| | | | Change-Id: I17cb6159c241772e4da50f233da34eb48a241c96
* sensor: lsm330dlc: allow exposing in /dev/inputSimon Shields2016-03-182-7/+18
| | | | | | don't make /dev/accelerometer mutually exclusive with /dev/input, though Change-Id: I576bb751bb1c590af97b1c60b6a1ca94a9539b81
* cpufreq: pegasusq: boost: drop more debuggingSimon Shields2016-03-181-1/+0
| | | | Change-Id: I607c3a8a70857bad2d3f13d666f987ae2c22329f
* cpufreq: pegasusq: boost: don't NULL timer functionSimon Shields2016-03-181-1/+0
| | | | Change-Id: Ibe8f0327f933ddf25a1ad0522293def0cdaaf515
* Enable TRIM on the Galaxy S2 familyLanchon2016-03-181-1/+11
| | | | | | | | | | | | WARNING!!! DO NOT MERGE THIS COMMIT WITHOUT VERIFYING THAT ALL THE REQUIRED PATCHES ARE APPLIED TO YOUR KERNEL. FAILURE TO HEED THIS WARNING MAY RESULT IN UNRECOVERABLE DEVICE BRICKS. For more information, please see: http://forum.xda-developers.com/galaxy-s2/development-derivatives/rom-brickbug-aftermath-speeding-t2843238 Change-Id: I193d5117ca63106265d6aac64c265b5c214612c1 (cherry picked from commit b784e843520149f55316bfc012338563dab3bbff)
* cpufreq: pegasusq: boost: tone down the logspamSimon Shields2016-03-181-4/+0
| | | | Change-Id: I945ec4bb014c9488b14b5a73fd86a22eb4a3a8c2
* cpufreq: pegasusq: add support for setting a boost freq/cpulockSimon Shields2016-03-182-1/+172
| | | | | | | | | | | | | | | | | | | | | | | | | | Currently, the pegasusq cpufreq driver has no way of allowing a userspace component (such as a powerhal) to indicate that the cpu should be brought to a higher clockspeed in anticipation of user input (such as on POWER_HINT_INTERACTION). This commit adds three interfaces to pegasusq, boost_freq and boost_mincpus, and boost_lock_time. boost_freq sets the minimum frequency for the cpus held online, and boost_mincpus specifies the minimum number of cpus to hold online. boost_lock_time is measured in nanoseconds, and is the amount of time to wait before restoring normal control. boost_mincpus and boost_freq will not have an effect until boost_lock_time != 0. Reading from boost_lock_time will return 1 if there is currently a boost, and 0 if there is not a boost. Writing 0 will cancel any current boost, and writing a non-zero number will cancel any current boost and begin boosting for that amount of time. Writing -1 will indefinitely boost until another value is written. This feature is hidden behind the CPU_FREQ_GOV_PEGASUSQ_BOOST Kconfig flag. Change-Id: I6e81dd3ec3af5d1408b99e136e5a63789b79dfbe
* staging: iio: use monotonic time since boot for event timestampsZiyan2016-03-181-8/+1
| | | | | | | | Recent Android versions are expecting a monotonic timestamp that includes the time since boot, not the time elapsed since boot while the device was awake. Change-Id: I68681be011162fe102287243f8e200b08d8c31e2
* i9100: Enable F2FSCaio Schnepper2016-03-181-0/+6
| | | | Change-Id: Ic8eb87571644fbe8ca0429e35932eae704b740b4
* i9100: Regenerate defconfigCaio Schnepper2016-03-181-11/+47
| | | | Change-Id: Id74edd83db7c9196546f2e38f40370bc33409b3b
* tcp_cubic: do not set epoch_start in the futureEric Dumazet2016-03-181-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | Tracking idle time in bictcp_cwnd_event() is imprecise, as epoch_start is normally set at ACK processing time, not at send time. Doing a proper fix would need to add an additional state variable, and does not seem worth the trouble, given CUBIC bug has been there forever before Jana noticed it. Let's simply not set epoch_start in the future, otherwise bictcp_update() could overflow and CUBIC would again grow cwnd too fast. This was detected thanks to a packetdrill test Neal wrote that was flaky before applying this fix. Change-Id: I600d3a8ac0ed1d70f3ff5cc6b7341ac13178f4f3 Fixes: 30927520dbae ("tcp_cubic: better follow cubic curve after idle period") Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: Yuchung Cheng <ycheng@google.com> Cc: Jana Iyengar <jri@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
* tcp_cubic: better follow cubic curve after idle periodEric Dumazet2016-03-181-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Jana Iyengar found an interesting issue on CUBIC : The epoch is only updated/reset initially and when experiencing losses. The delta "t" of now - epoch_start can be arbitrary large after app idle as well as the bic_target. Consequentially the slope (inverse of ca->cnt) would be really large, and eventually ca->cnt would be lower-bounded in the end to 2 to have delayed-ACK slow-start behavior. This particularly shows up when slow_start_after_idle is disabled as a dangerous cwnd inflation (1.5 x RTT) after few seconds of idle time. Jana initial fix was to reset epoch_start if app limited, but Neal pointed out it would ask the CUBIC algorithm to recalculate the curve so that we again start growing steeply upward from where cwnd is now (as CUBIC does just after a loss). Ideally we'd want the cwnd growth curve to be the same shape, just shifted later in time by the amount of the idle period. Change-Id: Ia99e2743517729b1c0589fbb8db9965ec806043b Reported-by: Jana Iyengar <jri@google.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Yuchung Cheng <ycheng@google.com> Signed-off-by: Neal Cardwell <ncardwell@google.com> Cc: Stephen Hemminger <stephen@networkplumber.org> Cc: Sangtae Ha <sangtae.ha@gmail.com> Cc: Lawrence Brakmo <lawrence@brakmo.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
generated by cgit v1.1 at 2024-04-29 16:02:08 +0000