aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Revert "proc: Remove verifiedbootstate flag from /proc/cmdline"lp-5.1Moyster2016-11-241-27/+1
| | | | | | This commit breaks Offline Charging mode on Mediatek platforms (at least mt6753 and mt6795) This reverts commit 81cd48af4ce91983fa556039f52bdede850c4e52.
* Revert "hand-pick: mediatek:remove unnecessary sido call flow"Moyster2016-11-111-0/+12
| | | | This reverts commit 9a7858491639342b5d3c8d496d3b9370d2330591.
* wlan: WiFi Direct CTS fixsdragonpt2016-11-116-11/+66
| | | | | | | | | | | | | | | | | | | | | | Cylen Yao <cylen.yao@mediatek.com> Details: 1. WiFi Direct CTS tests will fail as supplicant and driver could not keep sync in following case: 1.1 supplicant will request channel when do p2p listen, but driver/firmware has not switch to the target channel when supplicant get remain on channel credit by call driver API of remain on channel; This will make supplicant and driver in unsync state which will make supplicant fail to go to listen state randomly. 1.2 Supplicant and driver will also keep unsync when do mgmt frame TX; supplicant will do other task once mgmt frame TX is returned by calling driver API mgmt_tx, but, driver has not actually TX the mgmt frame out. In extremely case, driver will drop the second mgmt frame if the previous on has not been TX out, just as the group owner test case.
* tty: Properly fix memleak of alloc_piddragonpt2016-11-111-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Cylen Yao <cylen.yao@mediatek.com> bug: 7845126 MT67x2 Memleak is due to unreleased pid->count, which execute in function: get_pid()(pid->count++) and put_pid()(pid->count--). The race condition as following: task[dumpsys] task[adbd] in disassociate_ctty() in tty_signal_session_leader() ----------------------- ------------------------- tty = get_current_tty(); // tty is not NULL ... spin_lock_irq(&current->sighand->siglock); put_pid(current->signal->tty_old_pgrp); current->signal->tty_old_pgrp = NULL; spin_unlock_irq(&current->sighand->siglock); spin_lock_irq(&p->sighand->siglock); ... p->signal->tty = NULL; ... spin_unlock_irq(&p->sighand->siglock); tty = get_current_tty(); // tty NULL, goto else branch by accident. if (tty) { ... put_pid(tty_session); put_pid(tty_pgrp); ... } else { print msg } in task[dumpsys], in disassociate_ctty(), tty is set NULL by task[adbd], tty_signal_session_leader(), then it goto else branch and lack of put_pid(), cause memleak. move spin_unlock(sighand->siglock) after get_current_tty() can avoid the race and fix the memleak.
* KBUILD_CFLAGS: Some more tuningcm2016-11-111-1/+1
| | | | use -ftree-vectorize
* KBUILD_CFLAGS: Some tuningcm2016-11-111-1/+1
| | | | use cortex-a53 and arm platf proper optimized flags
* Fix "Security Vulnerability - kernel info leak of wifi driver"cm2016-11-111-7/+14
|
* stackprotector: Introduce CONFIG_CC_STACKPROTECTOR_STRONGKees Cook2016-11-113-4/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changes the stack protector config option into a choice of "None", "Regular", and "Strong": CONFIG_CC_STACKPROTECTOR_NONE CONFIG_CC_STACKPROTECTOR_REGULAR CONFIG_CC_STACKPROTECTOR_STRONG "Regular" means the old CONFIG_CC_STACKPROTECTOR=y option. "Strong" is a new mode introduced by this patch. With "Strong" the kernel is built with -fstack-protector-strong (available in gcc 4.9 and later). This option increases the coverage of the stack protector without the heavy performance hit of -fstack-protector-all. For reference, the stack protector options available in gcc are: -fstack-protector-all: Adds the stack-canary saving prefix and stack-canary checking suffix to _all_ function entry and exit. Results in substantial use of stack space for saving the canary for deep stack users (e.g. historically xfs), and measurable (though shockingly still low) performance hit due to all the saving/checking. Really not suitable for sane systems, and was entirely removed as an option from the kernel many years ago. -fstack-protector: Adds the canary save/check to functions that define an 8 (--param=ssp-buffer-size=N, N=8 by default) or more byte local char array. Traditionally, stack overflows happened with string-based manipulations, so this was a way to find those functions. Very few total functions actually get the canary; no measurable performance or size overhead. -fstack-protector-strong Adds the canary for a wider set of functions, since it's not just those with strings that have ultimately been vulnerable to stack-busting. With this superset, more functions end up with a canary, but it still remains small compared to all functions with only a small change in performance. Based on the original design document, a function gets the canary when it contains any of: - local variable's address used as part of the right hand side of an assignment or function argument - local variable is an array (or union containing an array), regardless of array type or length - uses register local variables https://docs.google.com/a/google.com/document/d/1xXBH6rRZue4f296vGt9YQcuLVQHeE516stHwt8M9xyU Find below a comparison of "size" and "objdump" output when built with gcc-4.9 in three configurations: - defconfig 11430641 kernel text size 36110 function bodies - defconfig + CONFIG_CC_STACKPROTECTOR_REGULAR 11468490 kernel text size (+0.33%) 1015 of 36110 functions are stack-protected (2.81%) - defconfig + CONFIG_CC_STACKPROTECTOR_STRONG via this patch 11692790 kernel text size (+2.24%) 7401 of 36110 functions are stack-protected (20.5%) With -strong, ARM's compressed boot code now triggers stack protection, so a static guard was added. Since this is only used during decompression and was never used before, the exposure here is very small. Once it switches to the full kernel, the stack guard is back to normal. Chrome OS has been using -fstack-protector-strong for its kernel builds for the last 8 months with no problems. Signed-off-by: Kees Cook <keescook@chromium.org> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Michal Marek <mmarek@suse.cz> Cc: Russell King <linux@arm.linux.org.uk> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Paul Mundt <lethal@linux-sh.org> Cc: James Hogan <james.hogan@imgtec.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Shawn Guo <shawn.guo@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mips@linux-mips.org Cc: linux-arch@vger.kernel.org Link: http://lkml.kernel.org/r/1387481759-14535-3-git-send-email-keescook@chromium.org [ Improved the changelog and descriptions some more. ] Signed-off-by: Ingo Molnar <mingo@kernel.org> Git-commit: 8779657d29c0ebcc0c94ede4df2f497baf1b563f Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Change-Id: I0c53785c54b9c2bedd6134fb959b59d1d1afb0ef Signed-off-by: David Brown <davidb@codeaurora.org>
* stackprotector: Unify the HAVE_CC_STACKPROTECTOR logic between architecturesKees Cook2016-11-119-46/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of duplicating the CC_STACKPROTECTOR Kconfig and Makefile logic in each architecture, switch to using HAVE_CC_STACKPROTECTOR and keep everything in one place. This retains the x86-specific bug verification scripts. Signed-off-by: Kees Cook <keescook@chromium.org> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Michal Marek <mmarek@suse.cz> Cc: Russell King <linux@arm.linux.org.uk> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Paul Mundt <lethal@linux-sh.org> Cc: James Hogan <james.hogan@imgtec.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Shawn Guo <shawn.guo@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mips@linux-mips.org Cc: linux-arch@vger.kernel.org Link: http://lkml.kernel.org/r/1387481759-14535-2-git-send-email-keescook@chromium.org Signed-off-by: Ingo Molnar <mingo@kernel.org> [davidb@codeaurora.org: Simple Kconfig merge resolution] Git-commit: 19952a92037e752f9d3bbbad552d596f9a56e146 Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Change-Id: I6e430de3c79306724e90ea1178f242145c39f059 Signed-off-by: David Brown <davidb@codeaurora.org> Conflicts: arch/x86/Kconfig
* defconfig: enable CC_STACKPROTECTOR-STRONGMoyster2016-11-111-0/+4
|
* hardcode LINUX_COMPILE_BY and COMPILE_HOST to linux@linux-userMoyster2016-11-081-0/+11
|
* defconfig : So wrong...Moyster2016-11-071-2/+2
| | | | | | | | | Used to be, I could make the pieces fit Break the edges, force fit all of this How could I ever be so wrong? At our base, we are doomed once we begin Kinda makes you wonder, "What's the sense?" How could I ever be so wrong?
* regen defconfigMoyster2016-11-071-14/+6
|
* mediatek: battery: Report the voltage in the correct scaleDiogo Ferreira2016-11-071-2/+2
| | | | | | The framework expects microvolts but we were reporting millivolts. Change-Id: I16a38e71e7cc1d87278bed7440fcdfefae34955f
* defconfig: don't build old ext3Moyster2016-11-071-3/+3
|
* Regen Defconfig: Remove Deprecated FSscafroglia932016-11-071-3/+3
|
* proc: much faster /proc/vmstatFrancisco Franco2016-11-071-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Every current KDE system has process named ksysguardd polling files below once in several seconds: $ strace -e trace=open -p $(pidof ksysguardd) Process 1812 attached open("/etc/mtab", O_RDONLY|O_CLOEXEC) = 8 open("/etc/mtab", O_RDONLY|O_CLOEXEC) = 8 open("/proc/net/dev", O_RDONLY) = 8 open("/proc/net/wireless", O_RDONLY) = -1 ENOENT (No such file or directory) open("/proc/stat", O_RDONLY) = 8 open("/proc/vmstat", O_RDONLY) = 8 Hell knows what it is doing but speed up reading /proc/vmstat by 33%! Benchmark is open+read+close 1.000.000 times. BEFORE $ perf stat -r 10 taskset -c 3 ./proc-vmstat Performance counter stats for 'taskset -c 3 ./proc-vmstat' (10 runs): 13146.768464 task-clock (msec) # 0.960 CPUs utilized ( +- 0.60% ) 15 context-switches # 0.001 K/sec ( +- 1.41% ) 1 cpu-migrations # 0.000 K/sec ( +- 11.11% ) 104 page-faults # 0.008 K/sec ( +- 0.57% ) 45,489,799,349 cycles # 3.460 GHz ( +- 0.03% ) 9,970,175,743 stalled-cycles-frontend # 21.92% frontend cycles idle ( +- 0.10% ) 2,800,298,015 stalled-cycles-backend # 6.16% backend cycles idle ( +- 0.32% ) 79,241,190,850 instructions # 1.74 insn per cycle # 0.13 stalled cycles per insn ( +- 0.00% ) 17,616,096,146 branches # 1339.956 M/sec ( +- 0.00% ) 176,106,232 branch-misses # 1.00% of all branches ( +- 0.18% ) 13.691078109 seconds time elapsed ( +- 0.03% ) ^^^^^^^^^^^^ AFTER $ perf stat -r 10 taskset -c 3 ./proc-vmstat Performance counter stats for 'taskset -c 3 ./proc-vmstat' (10 runs): 8688.353749 task-clock (msec) # 0.950 CPUs utilized ( +- 1.25% ) 10 context-switches # 0.001 K/sec ( +- 2.13% ) 1 cpu-migrations # 0.000 K/sec 104 page-faults # 0.012 K/sec ( +- 0.56% ) 30,384,010,730 cycles # 3.497 GHz ( +- 0.07% ) 12,296,259,407 stalled-cycles-frontend # 40.47% frontend cycles idle ( +- 0.13% ) 3,370,668,651 stalled-cycles-backend # 11.09% backend cycles idle ( +- 0.69% ) 28,969,052,879 instructions # 0.95 insn per cycle # 0.42 stalled cycles per insn ( +- 0.01% ) 6,308,245,891 branches # 726.058 M/sec ( +- 0.00% ) 214,685,502 branch-misses # 3.40% of all branches ( +- 0.26% ) 9.146081052 seconds time elapsed ( +- 0.07% ) ^^^^^^^^^^^ vsnprintf() is slow because: 1. format_decode() is busy looking for format specifier: 2 branches per character (not in this case, but in others) 2. approximately million branches while parsing format mini language and everywhere 3. just look at what string() does /proc/vmstat is good case because most of its content are strings Link: http://lkml.kernel.org/r/20160806125455.GA1187@p183.telecom.by Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Andi Kleen <andi@firstfloor.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
* arm64: kill off the libgcc dependencyFrancisco Franco2016-11-071-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | The arm64 kernel builds fine without the libgcc. Actually it should not be used at all in the kernel. The following are the reasons indicated by Russell King: Although libgcc is part of the compiler, libgcc is built with the expectation that it will be running in userland - it expects to link to a libc. That's why you can't build libgcc without having the glibc headers around. [...] Meanwhile, having the kernel build the compiler support functions that it needs ensures that (a) we know what compiler support functions are being used, (b) we know the implementation of those support functions are sane for use in the kernel, (c) we can build them with appropriate compiler flags for best performance, and (d) we remove an unnecessary dependency on the build toolchain. Signed-off-by: Kevin Hao <haokexin@gmail.com> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> (cherry picked from commit d67703a) Signed-off-by: Alex Shi <alex.shi@linaro.org> Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
* proc: Remove verifiedbootstate flag from /proc/cmdlineSultanxda2016-11-071-1/+27
| | | | | | | | | | | | Userspace parses this and sets the ro.boot.verifiedbootstate prop according to the value that this flag has. When ro.boot.verifiedbootstate is not 'green', SafetyNet is tripped and fails the CTS test. Hide verifiedbootstate from /proc/cmdline in order to fix the failed SafetyNet CTS check. Signed-off-by: Sultanxda <sultanxda@gmail.com> Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
* defconfig: enable dummy0 interfaceMoyster2016-11-071-1/+1
|
* defconfigMoyster2016-11-071-2/+3
|
* ping: fix null pointer exception (seen in speedtest app)DerTeufel2016-11-071-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [30409.811801]<5> (5)[29555:ping]SELinux: security field of sock is null!! [30409.811808]<5> (5)[29555:ping]SELinux: security field of sock is null!! [30409.811817]<5> (5)[29555:ping]SELinux: security field of sock is null!! [30409.811823]<5> (5)[29555:ping]SELinux: security field of sock is null!! [30409.811833]<5> (5)[29555:ping]SELinux: security field of sock is null!! [30409.811839]<5> (5)[29555:ping]SELinux: security field of sock is null!! [30409.811848]<5> (5)[29555:ping]SELinux: security field of sock is null!! [30409.811855]<5> (5)[29555:ping]SELinux: security field of sock is null!! [30409.811869]<5> (5)[29555:ping]Unable to handle kernel paging request at virtual address 5f37d1ba1e0fb303 [30409.811878]<5> (5)[29555:ping]pgd = ffffffc00fa8c000 [30409.811884][5f37d1ba1e0fb303] *pgd=0000000000000000 [30409.811893]<5> (5)[29555:ping][KERN Warning] ERROR/WARN forces debug_lock off! [30409.811899]<5> (5)[29555:ping][KERN Warning] check backtrace: [30409.811910]<5> (5)[29555:ping]CPU: 5 PID: 29555 Comm: ping Tainted: G W 3.10.90-DragonDevil_Jiayu.de #4 [30409.811918]<5> (5)[29555:ping]Call trace: [30409.811933]<5> (5)[29555:ping][<ffffffc000088aec>] dump_backtrace+0x0/0x16c [30409.811943]<5> (5)[29555:ping][<ffffffc000088c68>] show_stack+0x10/0x1c [30409.811956]<5> (5)[29555:ping][<ffffffc0009bff20>] dump_stack+0x1c/0x28 [30409.811967]<5> (5)[29555:ping][<ffffffc0002fb9f0>] debug_locks_off+0x44/0x5c [30409.811978]<5> (5)[29555:ping][<ffffffc000099f10>] oops_enter+0xc/0x28 [30409.811988]<5> (5)[29555:ping][<ffffffc000088c9c>] die+0x28/0x1d8 [30409.811998]<5> (5)[29555:ping][<ffffffc0009bda84>] __do_kernel_fault.part.5+0x70/0x84 [30409.812009]<5> (5)[29555:ping][<ffffffc0000942c4>] do_bad_area+0x90/0x94 [30409.812019]<5> (5)[29555:ping][<ffffffc000094310>] do_translation_fault+0x30/0x4c [30409.812028]<5> (5)[29555:ping][<ffffffc0000813f8>] do_mem_abort+0x38/0x9c [30409.812036]<5> (5)[29555:ping]Exception stack(0xffffffc0876cf8f0 to 0xffffffc0876cfac4) [30409.812046]<5> (5)[29555:ping]f8e0: 876cfb28 ffffffc0 876cc000 ffffffc0 [30409.812056]<5> (5)[29555:ping]f900: 876cfab0 ffffffc0 002a0018 ffffffc0 00df2008 ffffffc0 00df2008 ffffffc0 [30409.812066]<5> (5)[29555:ping]f920: 876cf930 ffffffc0 009cd040 ffffffc0 876cf940 ffffffc0 000c3cdc ffffffc0 [30409.812076]<5> (5)[29555:ping]f940: 876cf960 ffffffc0 0009b974 ffffffc0 00df2008 ffffffc0 00df1000 ffffffc0 [30409.812086]<5> (5)[29555:ping]f960: 876cf970 ffffffc0 009cd000 ffffffc0 876cf980 ffffffc0 0009c0dc ffffffc0 [30409.812096]<5> (5)[29555:ping]f980: 876cfa20 ffffffc0 009bdd38 ffffffc0 00000000 00000000 8ec6c9c0 ffffffc0 [30409.812106]<5> (5)[29555:ping]f9a0: 00000002 00000000 876cc000 ffffffc0 002a0144 ffffffc0 876cfbc0 ffffffc0 [30409.812116]<5> (5)[29555:ping]f9c0: 876cfd50 ffffffc0 00000000 00000000 000000d4 00000000 00000004 00000000 [30409.812125]<5> (5)[29555:ping]f9e0: 86544000 00000055 000003e8 00000000 0000000a 00000000 000003e8 00000000 [30409.812135]<5> (5)[29555:ping]fa00: 00000001 00000000 000000c0 00000000 00838260 ffffffc0 9c13b0c4 0000007f [30409.812145]<5> (5)[29555:ping]fa20: 00000001 00000000 876cfb28 ffffffc0 1e0fb303 5f37d1ba 00000194 00000000 [30409.812155]<5> (5)[29555:ping]fa40: 00000000 00000000 876cfe88 ffffffc0 876cfd50 ffffffc0 876cfdd0 ffffffc0 [30409.812165]<5> (5)[29555:ping]fa60: ebec47e8 0000007f 000000c0 00000000 876cfe88 ffffffc0 876cfab0 ffffffc0 [30409.812174]<5> (5)[29555:ping]fa80: 002a000c ffffffc0 876cfab0 ffffffc0 002a0018 ffffffc0 60000145 00000000 [30409.812184]<5> (5)[29555:ping]faa0: 876cfb28 ffffffc0 00000001 00000000 876cfb60 ffffffc0 002a0164 ffffffc0 [30409.812191]<5> (5)[29555:ping]fac0: 876cfc38 [30409.812200]<5> (5)[29555:ping][<ffffffc000083c58>] el1_da+0x1c/0x88 [30409.812213]<5> (5)[29555:ping][<ffffffc0002a0160>] selinux_socket_recvmsg+0x1c/0x28 [30409.812225]<5> (5)[29555:ping][<ffffffc00029bfbc>] security_socket_recvmsg+0x14/0x20 [30409.812237]<5> (5)[29555:ping][<ffffffc0008347f0>] sock_recvmsg+0x74/0xf4 [30409.812248]<5> (5)[29555:ping][<ffffffc000834d18>] ___sys_recvmsg+0xcc/0x220 [30409.812259]<5> (5)[29555:ping][<ffffffc000838218>] __sys_recvmsg+0x3c/0x84 [30409.812270]<5> (5)[29555:ping][<ffffffc00083826c>] SyS_recvmsg+0xc/0x20 [30409.812278]<5>-(5)[29555:ping]Internal error: Oops: 96000004 [#1] PREEMPT SMP [30409.812284]disable aee kernel api
* ping: Fix race in free in receive pathsubashab@codeaurora.org2016-11-071-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit fc752f1f43c1c038a2c6ae58cc739ebb5953ccb0 ] An exception is seen in ICMP ping receive path where the skb destructor sock_rfree() tries to access a freed socket. This happens because ping_rcv() releases socket reference with sock_put() and this internally frees up the socket. Later icmp_rcv() will try to free the skb and as part of this, skb destructor is called and which leads to a kernel panic as the socket is freed already in ping_rcv(). -->|exception -007|sk_mem_uncharge -007|sock_rfree -008|skb_release_head_state -009|skb_release_all -009|__kfree_skb -010|kfree_skb -011|icmp_rcv -012|ip_local_deliver_finish Fix this incorrect free by cloning this skb and processing this cloned skb instead. This patch was suggested by Eric Dumazet Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org> Cc: Eric Dumazet <edumazet@google.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* tcp: make challenge acks less predictableCharles (Chas) Williams2016-11-071-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 75ff39ccc1bd5d3c455b6822ab09e533c551f758 upstream. From: Eric Dumazet <edumazet@google.com> Yue Cao claims that current host rate limiting of challenge ACKS (RFC 5961) could leak enough information to allow a patient attacker to hijack TCP sessions. He will soon provide details in an academic paper. This patch increases the default limit from 100 to 1000, and adds some randomization so that the attacker can no longer hijack sessions without spending a considerable amount of probes. Based on initial analysis and patch from Linus. Note that we also have per socket rate limiting, so it is tempting to remove the host limit in the future. v2: randomize the count of challenge acks per second, not the period. Fixes: 282f23c6ee34 ("tcp: implement RFC 5961 3.2") Reported-by: Yue Cao <ycao009@ucr.edu> Signed-off-by: Eric Dumazet <edumazet@google.com> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: Yuchung Cheng <ycheng@google.com> Cc: Neal Cardwell <ncardwell@google.com> Acked-by: Neal Cardwell <ncardwell@google.com> Acked-by: Yuchung Cheng <ycheng@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> [ ciwillia: backport to 3.10-stable ] Signed-off-by: Chas Williams <ciwillia@brocade.com> Signed-off-by: Willy Tarreau <w@1wt.eu>
* cleanup: delete 3.10.101 patch from /Moyster2016-11-071-1493/+0
|
* cleanup infosMoyster2016-11-074-110/+9
| | | | readme update
* Linux 3.10.104Willy Tarreau2016-11-071-1/+1
|
* mm: remove gup_flags FOLL_WRITE games from __get_user_pages()Linus Torvalds2016-11-072-2/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619 upstream. This is an ancient bug that was actually attempted to be fixed once (badly) by me eleven years ago in commit 4ceb5db9757a ("Fix get_user_pages() race for write access") but that was then undone due to problems on s390 by commit f33ea7f404e5 ("fix get_user_pages bug"). In the meantime, the s390 situation has long been fixed, and we can now fix it by checking the pte_dirty() bit properly (and do it better). The s390 dirty bit was implemented in abf09bed3cce ("s390/mm: implement software dirty bits") which made it into v3.9. Earlier kernels will have to look at the page state itself. Also, the VM has become more scalable, and what used a purely theoretical race back then has become easier to trigger. To fix it, we introduce a new internal FOLL_COW flag to mark the "yes, we already did a COW" rather than play racy games with FOLL_WRITE that is very fundamental, and then use the pte dirty flag to validate that the FOLL_COW flag is still valid. Reported-and-tested-by: Phil "not Paul" Oester <kernel@linuxace.com> Acked-by: Hugh Dickins <hughd@google.com> Reviewed-by: Michal Hocko <mhocko@suse.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Kees Cook <keescook@chromium.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Willy Tarreau <w@1wt.eu> Cc: Nick Piggin <npiggin@gmail.com> Cc: Greg Thelen <gthelen@google.com> Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> [wt: s/gup.c/memory.c; s/follow_page_pte/follow_page_mask; s/faultin_page/__get_user_page] Signed-off-by: Willy Tarreau <w@1wt.eu>
* xen-netback: ref count shared ringsWei Liu2016-11-073-2/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... so that we can make sure the rings are not freed until all SKBs in internal queues are consumed. 1. The VM is receiving packets through bonding + bridge + netback + netfront. 2. For some unknown reason at least one packet remains in the rx queue and is not delivered to the domU immediately by netback. 3. The VM finishes shutting down. 4. The shared ring between dom0 and domU is freed. 5. then xen-netback continues processing the pending requests and tries to put the packet into the now already released shared ring. > XXXlan0: port 9(vif26.0) entered disabled state > BUG: unable to handle kernel paging request at ffffc900108641d8 > IP: [<ffffffffa04147dc>] xen_netbk_rx_action+0x18b/0x6f0 [xen_netback] > PGD 57e20067 PUD 57e21067 PMD 571a7067 PTE 0 > Oops: 0000 [#1] SMP > ... > CPU: 0 PID: 12587 Comm: netback/0 Not tainted 3.10.0-ucs58-amd64 #1 Debian 3.10.11-1.58.201405060908 > Hardware name: FUJITSU PRIMERGY BX620 S6/D3051, BIOS 080015 Rev.3C78.3051 07/22/2011 > task: ffff880004b067c0 ti: ffff8800561ec000 task.ti: ffff8800561ec000 > RIP: e030:[<ffffffffa04147dc>] [<ffffffffa04147dc>] xen_netbk_rx_action+0x18b/0x6f0 [xen_netback] > RSP: e02b:ffff8800561edce8 EFLAGS: 00010202 > RAX: ffffc900104adac0 RBX: ffff8800541e95c0 RCX: ffffc90010864000 > RDX: 000000000000003b RSI: 0000000000000000 RDI: ffff880040014380 > RBP: ffff8800570e6800 R08: 0000000000000000 R09: ffff880004799800 > R10: ffffffff813ca115 R11: ffff88005e4fdb08 R12: ffff880054e6f800 > R13: ffff8800561edd58 R14: ffffc900104a1000 R15: 0000000000000000 > FS: 00007f19a54a8700(0000) GS:ffff88005da00000(0000) knlGS:0000000000000000 > CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b > CR2: ffffc900108641d8 CR3: 0000000054cb3000 CR4: 0000000000002660 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > Stack: > ffff880004b06ba0 0000000000000000 ffff88005da13ec0 ffff88005da13ec0 > 0000000004b067c0 ffffc900104a8ac0 ffffc900104a1020 000000005da13ec0 > 0000000000000000 0000000000000001 ffffc900104a8ac0 ffffc900104adac0 > Call Trace: > [<ffffffff813ca32d>] ? _raw_spin_lock_irqsave+0x11/0x2f > [<ffffffffa0416033>] ? xen_netbk_kthread+0x174/0x841 [xen_netback] > [<ffffffff8105d373>] ? wake_up_bit+0x20/0x20 > [<ffffffffa0415ebf>] ? xen_netbk_tx_build_gops+0xce8/0xce8 [xen_netback] > [<ffffffff8105cd73>] ? kthread_freezable_should_stop+0x56/0x56 > [<ffffffffa0415ebf>] ? xen_netbk_tx_build_gops+0xce8/0xce8 [xen_netback] > [<ffffffff8105ce1e>] ? kthread+0xab/0xb3 > [<ffffffff81003638>] ? xen_end_context_switch+0xe/0x1c > [<ffffffff8105cd73>] ? kthread_freezable_should_stop+0x56/0x56 > [<ffffffff813cfbfc>] ? ret_from_fork+0x7c/0xb0 > [<ffffffff8105cd73>] ? kthread_freezable_should_stop+0x56/0x56 > Code: 8b b3 d0 00 00 00 48 8b bb d8 00 00 00 0f b7 74 37 02 89 70 08 eb 07 c7 40 08 00 00 00 00 89 d2 c7 40 04 00 00 00 00 48 83 c2 08 <0f> b7 34 d1 89 30 c7 44 24 60 00 00 00 00 8b 44 d1 04 89 44 24 > RIP [<ffffffffa04147dc>] xen_netbk_rx_action+0x18b/0x6f0 [xen_netback] > RSP <ffff8800561edce8> > CR2: ffffc900108641d8 Track the shared ring buffer being unmapped and drop those packets. Ref-count the rings as followed: map -> set to 1 start_xmit -> inc when queueing SKB to internal queue rx_action -> dec after finishing processing a SKB unmap -> dec and wait to be 0 Note that this is different from ref counting the vif structure itself. Currently only guest Rx path is taken care of because that's where the bug surfaced. This bug doesn't exist in kernel >=3.12 as multi-queue support was added there. Link: <https://lists.xenproject.org/archives/html/xen-devel/2014-06/msg00818.html> Signed-off-by: Wei Liu <wei.liu2@citrix.com> Signed-off-by: Philipp Hahn <hahn@univention.de> Cc: David Vrabel <david.vrabel@citrix.com> Tested-by: Philipp Hahn <hahn@univention.de> Signed-off-by: Willy Tarreau <w@1wt.eu>
* security: let security modules use PTRACE_MODE_* with bitmasksJann Horn2016-11-071-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | commit 3dfb7d8cdbc7ea0c2970450e60818bb3eefbad69 upstream. It looks like smack and yama weren't aware that the ptrace mode can have flags ORed into it - PTRACE_MODE_NOAUDIT until now, but only for /proc/$pid/stat, and with the PTRACE_MODE_*CREDS patch, all modes have flags ORed into them. Signed-off-by: Jann Horn <jann@thejh.net> Acked-by: Kees Cook <keescook@chromium.org> Acked-by: Casey Schaufler <casey@schaufler-ca.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Morris <james.l.morris@oracle.com> Cc: "Serge E. Hallyn" <serge.hallyn@ubuntu.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Willy Tarreau <w@1wt.eu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> [wt: no smk_ptrace_mode() in 3.10] Signed-off-by: Willy Tarreau <w@1wt.eu>
* MIPS: KVM: Check for pfn noslot caseJames Hogan2016-11-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit ba913e4f72fc9cfd03dad968dfb110eb49211d80 upstream. When mapping a page into the guest we error check using is_error_pfn(), however this doesn't detect a value of KVM_PFN_NOSLOT, indicating an error HVA for the page. This can only happen on MIPS right now due to unusual memslot management (e.g. being moved / removed / resized), or with an Enhanced Virtual Memory (EVA) configuration where the default KVM_HVA_ERR_* and kvm_is_error_hva() definitions are unsuitable (fixed in a later patch). This case will be treated as a pfn of zero, mapping the first page of physical memory into the guest. It would appear the MIPS KVM port wasn't updated prior to being merged (in v3.10) to take commit 81c52c56e2b4 ("KVM: do not treat noslot pfn as a error pfn") into account (merged v3.8), which converted a bunch of is_error_pfn() calls to is_error_noslot_pfn(). Switch to using is_error_noslot_pfn() instead to catch this case properly. Fixes: 858dd5d45733 ("KVM/MIPS32: MMU/TLB operations for the Guest.") Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Radim Krčmář" <rkrcmar@redhat.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Cc: kvm@vger.kernel.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> [james.hogan@imgtec.com: Backport to v3.16.y] Signed-off-by: James Hogan <james.hogan@imgtec.com> Signed-off-by: Willy Tarreau <w@1wt.eu>
* mm: thp: fix SMP race condition between THP page fault and MADV_DONTNEEDAndrea Arcangeli2016-11-071-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit ad33bb04b2a6cee6c1f99fabb15cddbf93ff0433 upstream. pmd_trans_unstable()/pmd_none_or_trans_huge_or_clear_bad() were introduced to locklessy (but atomically) detect when a pmd is a regular (stable) pmd or when the pmd is unstable and can infinitely transition from pmd_none() and pmd_trans_huge() from under us, while only holding the mmap_sem for reading (for writing not). While holding the mmap_sem only for reading, MADV_DONTNEED can run from under us and so before we can assume the pmd to be a regular stable pmd we need to compare it against pmd_none() and pmd_trans_huge() in an atomic way, with pmd_trans_unstable(). The old pmd_trans_huge() left a tiny window for a race. Useful applications are unlikely to notice the difference as doing MADV_DONTNEED concurrently with a page fault would lead to undefined behavior. [js] 3.12 backport: no pmd_devmap in 3.12 yet. [akpm@linux-foundation.org: tidy up comment grammar/layout] Signed-off-by: Andrea Arcangeli <aarcange@redhat.com> Reported-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: Vlastimil Babka <vbabka@suse.cz> Signed-off-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Willy Tarreau <w@1wt.eu>
* ACPI / sysfs: fix error code in get_status()Dan Carpenter2016-11-071-4/+3
| | | | | | | | | | | | | | | | | commit f18ebc211e259d4f591e39e74b2aa2de226c9a1d upstream. The problem with ornamental, do-nothing gotos is that they lead to "forgot to set the error code" bugs. We should be returning -EINVAL here but we don't. It leads to an uninitalized variable in counter_show(): drivers/acpi/sysfs.c:603 counter_show() error: uninitialized symbol 'status'. Fixes: 1c8fce27e275 (ACPI: introduce drivers/acpi/sysfs.c) Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Willy Tarreau <w@1wt.eu>
* staging: comedi: daqboard2000: bug fix board type matching codeIan Abbott2016-11-071-1/+1
| | | | | | | | | | | | | | | | | | commit 80e162ee9b31d77d851b10f8c5299132be1e120f upstream. `daqboard2000_find_boardinfo()` is supposed to check if the DaqBoard/2000 series model is supported, based on the PCI subvendor and subdevice ID. The current code is wrong as it is comparing the PCI device's subdevice ID to an expected, fixed value for the subvendor ID. It should be comparing the PCI device's subvendor ID to this fixed value. Correct it. Fixes: 7e8401b23e7f ("staging: comedi: daqboard2000: add back subsystem_device check") Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Cc: <stable@vger.kernel.org> # 3.7+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Willy Tarreau <w@1wt.eu>
* crypto: nx - off by one bug in nx_of_update_msc()Dan Carpenter2016-11-071-1/+1
| | | | | | | | | | | | | | | | commit e514cc0a492a3f39ef71b31590a7ef67537ee04b upstream. The props->ap[] array is defined like this: struct alg_props ap[NX_MAX_FC][NX_MAX_MODE][3]; So we can see that if msc->fc and msc->mode are == to NX_MAX_FC or NX_MAX_MODE then we're off by one. Fixes: ae0222b7289d ('powerpc/crypto: nx driver code supporting nx encryption') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Willy Tarreau <w@1wt.eu>
* megaraid_sas: Fix probing cards without io portYinghai Lu2016-11-072-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit e7f851684efb3377e9c93aca7fae6e76212e5680 upstream. Found one megaraid_sas HBA probe fails, [ 187.235190] scsi host2: Avago SAS based MegaRAID driver [ 191.112365] megaraid_sas 0000:89:00.0: BAR 0: can't reserve [io 0x0000-0x00ff] [ 191.120548] megaraid_sas 0000:89:00.0: IO memory region busy! and the card has resource like, [ 125.097714] pci 0000:89:00.0: [1000:005d] type 00 class 0x010400 [ 125.104446] pci 0000:89:00.0: reg 0x10: [io 0x0000-0x00ff] [ 125.110686] pci 0000:89:00.0: reg 0x14: [mem 0xce400000-0xce40ffff 64bit] [ 125.118286] pci 0000:89:00.0: reg 0x1c: [mem 0xce300000-0xce3fffff 64bit] [ 125.125891] pci 0000:89:00.0: reg 0x30: [mem 0xce200000-0xce2fffff pref] that does not io port resource allocated from BIOS, and kernel can not assign one as io port shortage. The driver is only looking for MEM, and should not fail. It turns out megasas_init_fw() etc are using bar index as mask. index 1 is used as mask 1, so that pci_request_selected_regions() is trying to request BAR0 instead of BAR1. Fix all related reference. Fixes: b6d5d8808b4c ("megaraid_sas: Use lowest memory bar for SR-IOV VF support") Signed-off-by: Yinghai Lu <yinghai@kernel.org> Acked-by: Kashyap Desai <kashyap.desai@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Willy Tarreau <w@1wt.eu>
* aacraid: Check size values after double-fetch from userDave Carroll2016-11-071-2/+11
| | | | | | | | | | | | | | | | | | | | | commit fa00c437eef8dc2e7b25f8cd868cfa405fcc2bb3 upstream. In aacraid's ioctl_send_fib() we do two fetches from userspace, one the get the fib header's size and one for the fib itself. Later we use the size field from the second fetch to further process the fib. If for some reason the size from the second fetch is different than from the first fix, we may encounter an out-of- bounds access in aac_fib_send(). We also check the sender size to insure it is not out of bounds. This was reported in https://bugzilla.kernel.org/show_bug.cgi?id=116751 and was assigned CVE-2016-6480. Reported-by: Pengfei Wang <wpengfeinudt@gmail.com> Fixes: 7c00ffa31 '[SCSI] 2.6 aacraid: Variable FIB size (updated patch)' Cc: stable@vger.kernel.org Signed-off-by: Dave Carroll <david.carroll@microsemi.com> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Willy Tarreau <w@1wt.eu>
* PCI: Limit config space size for Netronome NFP4000Simon Horman2016-11-071-0/+1
| | | | | | | | | | | | | | | | | | | commit c2e771b02792d222cbcd9617fe71482a64f52647 upstream. Like the NFP6000, the NFP4000 as an erratum where reading/writing to PCI config space addresses above 0x600 can cause the NFP to generate PCIe completion timeouts. Limit the NFP4000's PF's config space size to 0x600 bytes as is already done for the NFP6000. The NFP4000's VF is 0x6004 (PCI_DEVICE_ID_NETRONOME_NFP6000_VF), the same device ID as the NFP6000's VF. Thus, its config space is already limited by the existing use of quirk_nfp6000(). Signed-off-by: Simon Horman <simon.horman@netronome.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Willy Tarreau <w@1wt.eu>
* PCI: Add Netronome NFP4000 PF device IDSimon Horman2016-11-071-0/+1
| | | | | | | | | | | commit 69874ec233871a62e1bc8c89e643993af93a8630 upstream. Add the device ID for the PF of the NFP4000. The device ID for the VF, 0x6003, is already present as PCI_DEVICE_ID_NETRONOME_NFP6000_VF. Signed-off-by: Simon Horman <simon.horman@netronome.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Willy Tarreau <w@1wt.eu>
* PCI: Limit config space size for Netronome NFP6000 familyJason S. McMullan2016-11-071-0/+11
| | | | | | | | | | | | | | | | commit 9f33a2ae59f24452c1076749deb615bccd435ca9 upstream. The NFP6000 has an erratum where reading/writing to PCI config space addresses above 0x600 can cause the NFP to generate PCIe completion timeouts. Limit the NFP6000's config space size to 0x600 bytes. Signed-off-by: Jason S. McMullan <jason.mcmullan@netronome.com> [simon: edited changelog] Signed-off-by: Simon Horman <simon.horman@netronome.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Willy Tarreau <w@1wt.eu>
* PCI: Add Netronome vendor and device IDsJason S. McMullan2016-11-071-0/+6
| | | | | | | | | | | | | commit a755e169031dac9ebaed03302c4921687c271d62 upstream. Device IDs for the Netronome NFP3200, NFP3240, NFP6000, and NFP6000 SR-IOV devices. Signed-off-by: Jason S. McMullan <jason.mcmullan@netronome.com> [simon: edited changelog] Signed-off-by: Simon Horman <simon.horman@netronome.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Willy Tarreau <w@1wt.eu>
* PCI: Support PCIe devices with short cfg_sizeJason S. McMullan2016-11-071-9/+9
| | | | | | | | | | | | | | | | | | | | | | commit c20aecf6963d1273d8f6d61c042b4845441ca592 upstream. If a device quirk modifies the pci_dev->cfg_size to be less than PCI_CFG_SPACE_EXP_SIZE (4096), but greater than PCI_CFG_SPACE_SIZE (256), the PCI sysfs interface truncates the readable size to PCI_CFG_SPACE_SIZE. Allow sysfs access to config space up to cfg_size, even if the device doesn't support the entire 4096-byte PCIe config space. Note that pci_read_config() and pci_write_config() limit access to dev->cfg_size even though pcie_config_attr contains 4096 (the maximum size). Signed-off-by: Jason S. McMullan <jason.mcmullan@netronome.com> [simon: edited changelog] Signed-off-by: Simon Horman <simon.horman@netronome.com> [bhelgaas: more changelog edits] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Willy Tarreau <w@1wt.eu>
* Revert "powerpc/tm: Always reclaim in start_thread() for exec() class syscalls"Willy Tarreau2016-11-071-10/+0
| | | | | | | | | | This reverts commit 8110080dc53335d5dd99b123144a6174f19ffc65. Guenter noticed that this breaks PPC build when CONFIG_PPC_TRANSACTIONAL_MEM is set, because this patch was not for 3.10. Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Willy Tarreau <w@1wt.eu>
* KEYS: Fix ASN.1 indefinite length object parsingDavid Howells2016-11-071-7/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes CVE-2016-0758. In the ASN.1 decoder, when the length field of an ASN.1 value is extracted, it isn't validated against the remaining amount of data before being added to the cursor. With a sufficiently large size indicated, the check: datalen - dp < 2 may then fail due to integer overflow. Fix this by checking the length indicated against the amount of remaining data in both places a definite length is determined. Whilst we're at it, make the following changes: (1) Check the maximum size of extended length does not exceed the capacity of the variable it's being stored in (len) rather than the type that variable is assumed to be (size_t). (2) Compare the EOC tag to the symbolic constant ASN1_EOC rather than the integer 0. (3) To reduce confusion, move the initialisation of len outside of: for (len = 0; n > 0; n--) { since it doesn't have anything to do with the loop counter n. Change-Id: I2a103f4c191ff6c463d68d6fe703edd96aa8f0ef Ticket: PORRIDGE-485 Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Mimi Zohar <zohar@linux.vnet.ibm.com> Acked-by: David Woodhouse <David.Woodhouse@intel.com> Acked-by: Peter Jones <pjones@redhat.com>
* ANDROID: binder: Clear binder and cookie when setting handle in flat binder ↵Arve Hjønnevåg2016-11-071-0/+5
| | | | | | | | | | | struct Prevents leaking pointers between processes BUG: 30768347 Change-Id: Id898076926f658a1b8b27a3ccb848756b36de4ca Signed-off-by: Arve Hjønnevåg <arve@android.com> Ticket: PORRIDGE-499
* staging: android: Change %p to %pK in debug messagesDivya Ponnusamy2016-11-071-2/+2
| | | | | | | | | | | | The format specifier %p can leak kernel addresses while not valuing the kptr_restrict system settings. Use %pK instead of %p, which also evaluates whether kptr_restrict is set. Bug: 30148243 Change-Id: Ib1adf14e9620ad7b1bd3e962001c852610210d46 Signed-off-by: Divya Ponnusamy <pdivya@codeaurora.org> Ticket: PORRIDGE-499
* Bluetooth: Fix potential NULL dereference in RFCOMM bind callbackJaganath Kanakkassery2016-11-071-7/+12
| | | | | | | addr can be NULL and it should not be dereferenced before NULL checking. Signed-off-by: Jaganath Kanakkassery <jaganath.k@samsung.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* binder: prevent kptr leak by using %pK format specifierNick Desaulniers2016-11-071-1/+1
| | | | | | | | Works in conjunction with kptr_restrict. Bug: 30143283 Change-Id: I2b3ce22f4e206e74614d51453a1d59b7080ab05a (cherry picked from commit 7905a759cc685b58078483013cc584dc8327d118)
* arm64: perf: reject groups spanning multiple HW PMUsSuzuki K. Poulose2016-11-071-6/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The perf core implicitly rejects events spanning multiple HW PMUs, as in these cases the event->ctx will differ. However this validation is performed after pmu::event_init() is called in perf_init_event(), and thus pmu::event_init() may be called with a group leader from a different HW PMU. The ARM64 PMU driver does not take this fact into account, and when validating groups assumes that it can call to_arm_pmu(event->pmu) for any HW event. When the event in question is from another HW PMU this is wrong, and results in dereferencing garbage. This patch updates the ARM64 PMU driver to first test for and reject events from other PMUs, moving the to_arm_pmu and related logic after this test. Fixes a crash triggered by perf_fuzzer on Linux-4.0-rc2, with a CCI PMU present: Bad mode in Synchronous Abort handler detected, code 0x86000006 -- IABT (current EL) CPU: 0 PID: 1371 Comm: perf_fuzzer Not tainted 3.19.0+ #249 Hardware name: V2F-1XV7 Cortex-A53x2 SMM (DT) task: ffffffc07c73a280 ti: ffffffc07b0a0000 task.ti: ffffffc07b0a0000 PC is at 0x0 LR is at validate_event+0x90/0xa8 pc : [<0000000000000000>] lr : [<ffffffc000090228>] pstate: 00000145 sp : ffffffc07b0a3ba0 [< (null)>] (null) [<ffffffc0000907d8>] armpmu_event_init+0x174/0x3cc [<ffffffc00015d870>] perf_try_init_event+0x34/0x70 [<ffffffc000164094>] perf_init_event+0xe0/0x10c [<ffffffc000164348>] perf_event_alloc+0x288/0x358 [<ffffffc000164c5c>] SyS_perf_event_open+0x464/0x98c Code: bad PC value Also cleans up the code to use the arm_pmu only when we know that we are dealing with an arm pmu event. Cc: Will Deacon <will.deacon@arm.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Peter Ziljstra (Intel) <peterz@infradead.org> Signed-off-by: Suzuki K. Poulose <suzuki.poulose@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
* Replace %p with %pK to prevent leaking kernel addressMohamad Ayyash2016-11-071-1/+1
| | | | | | BUG: 27532522 Change-Id: Ic0710a9a8cfc682acd88ecf3bbfeece2d798c4a4 Signed-off-by: Mohamad Ayyash <mkayyash@google.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-03-14 00:47:05 +0000