On the low-class hardware like flo this only introduces issues
and performance degradation due to increased scheduler overhead.
Revert "arm: configs: flo: set CONFIG_HZ to 300"
This reverts commit 029a1baa6f.
Revert "ARM: msm: flo: fix idle_timeout value to 100ms"
This reverts commit a63fd90f21.
Revert "msm: kgsl: Fix direct references to HZ"
This reverts commit 38d48e1127.
Change-Id: Ib65977c959bff9cce43f5039f8f543e074992fec
Revert "sched_clock: Avoid corrupting hrtimer tree during suspend"
This reverts commit 8aad725c70.
Revert "sched_clock: Add support for >32 bit sched_clock"
This reverts commit 657eb100e4.
Revert "sched_clock: Use an hrtimer instead of timer"
This reverts commit b2ee62ec51.
Revert "sched_clock: Use seqcount instead of rolling our own"
This reverts commit 538b187b6e.
Revert "ARM: sched_clock: Load cycle count after epoch stabilizes"
This reverts commit 8c7175ba39.
Revert "sched_clock: Make ARM's sched_clock generic for all architectures"
This reverts commit ebb97da74a.
Revert "ARM: 7699/1: sched_clock: Add more notrace to prevent recursion"
This reverts commit 086da6a6c4.
Revert "ARM: make sched_clock just call a function pointer"
This reverts commit 0dd4fad6c9.
Revert "ARM: sched_clock: allow changing to higher frequency counter"
This reverts commit 4a3cf85432.
Change-Id: I98aaec7b554a2e11be4c551a864d952e0d8c3e22
The 'dir' parameter in xfrm_migrate() is a user-controlled byte which is used
as an array index. This can lead to an out-of-bound access, kernel lockup and
DoS. Add a check for the 'dir' value.
This fixes CVE-2017-11600.
Change-Id: Ic55eec5b4767ad1bd8328b382c35f7b213abc38d
References: https://bugzilla.redhat.com/show_bug.cgi?id=1474928
Fixes: 80c9abaabf ("[XFRM]: Extension for dynamic update of endpoint address(es)")
Cc: <stable@vger.kernel.org> # v2.6.21-rc1
Reported-by: "bo Zhang" <zhangbo5891001@gmail.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
SPS debugfs APIs can be called concurrently which can result
in dangling pointer access. This change synchronizes access
to the SPS debugfs buffer.
Change-Id: I409b3f0618f760cb67eba47b43c81d166cdae4aa
Signed-off-by: Siva Kumar Akkireddi <sivaa@codeaurora.org>
(cherry picked from commit de875dd095d3ec0906c77518d28f793e6c69a9da)
Add changes to drop assoc request and return error if RSNIE or
WPAIE parsing fail during parsing of assoc request.
CRs-Fixed: 2046578
Change-Id: I88d779399c2eba5d33c30144bf9600a1f3a00b77
(cherry picked from commit aae237dfbaf8edcf310eeb84b887b20e7e9c0ff3)
WEXT API was already obsoleted and should be removed.
Bug: 34199963
Change-Id: Iffb1c81afb9874120c64008c1072eebb8695c65f
Signed-off-by: Insun Song <insun.song@broadcom.com>
Bug: 32124445
(cherry picked from commit 9c5e11d70f)
The cache maintenance routines in ashmem were causing
several security issues. Since they are not being used
anymore by any drivers, its well to remove them entirely.
Bug: 34126808
Bug: 34173755
Bug: 34203176
CRs-Fixed: 1107034, 2001129, 2007786
Change-Id: I955e33d90b888d58db5cf6bb490905283374425b
Signed-off-by: Sudarshan Rajagopalan <sudaraja@codeaurora.org>
Signed-off-by: Dennis Cagle <d-cagle@codeaurora.org>
(cherry picked from commit e7f623aa1b8ba3b843c70eeae99aae95bddfe03d)
"file" can be already freed if bprm->file is NULL after
search_binary_handler() return. binfmt_script will do exactly that for
example. If the VM reuses the file after fput run(), this will result in
a use ater free.
So obtain d_is_su before search_binary_handler() runs.
This should explain this crash:
[25333.009554] Unable to handle kernel NULL pointer dereference at virtual address 00000185
[..]
[25333.009918] [2: am:21861] PC is at do_execve+0x354/0x474
Change-Id: I2a8a814d1c0aa75625be83cb30432cf13f1a0681
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
The list usage in msm_bus_dbg driver are not correct which will cause
kernel panic.
. The list operation should be protected by a lock, e.g. mutex_lock.
. The list entry should only be operated on a valid entry.
Change-Id: I19efeb346d1bacf129ccfd7a6511bc795c029afc
Signed-off-by: Lianwei Wang <lian-wei.wang@motorola.com>
Reviewed-on: http://gerrit.pcs.mot.com/384275
Reviewed-by: Guo-Jian Chen <A21757@motorola.com>
Reviewed-by: Ke Lv <a2435c@motorola.com>
Tested-by: Jira Key <JIRAKEY@motorola.com>
Reviewed-by: Jeffrey Carlyle <jeff.carlyle@motorola.com>
Reviewed-by: Check Patch <CHEKPACH@motorola.com>
Reviewed-by: Klocwork kwcheck <klocwork-kwcheck@sourceforge.mot.com>
Reviewed-by: Tao Hu <taohu@motorola.com>
(cherry picked from commit d109d8d7e2998a635406215a559e298fa7ef4bb8)
Use proper synchronization to ensure driver file is opened
only once.
CRs-Fixed: 2023513
Change-Id: I71e55e2d487fe561d3f596590b3e8102c5e921b5
Signed-off-by: Trishansh Bhardwaj <tbhardwa@codeaurora.org>
(cherry picked from commit 84f8c42e5d848b1d04f49d253f98296e8c2280b9)
Validate a buffer virtual address is fully within the region before
returning the region to ensure functionality for an extended edge
case.
Change-Id: Iba3e080889980f393d6a9f0afe0231408b92d654
Signed-off-by: Siena Richard <sienar@codeaurora.org>
CRs-fixed: 1108461
(cherry picked from commit 208e72e59c8411e75d4118b48648a5b7d42b1682)
msm-compr-q6-v2.c and msm-compr-q6-v2.h are no longer used.
CRs-Fixed: 2022953
Change-Id: I856d90a212a3e123a2c8b80092aff003f7c608c7
Signed-off-by: Xiaojun Sang <xsang@codeaurora.org>
(cherry picked from commit dc333eb1c31b5bdd2b6375d7cb890086d8f27d8b)
This was found during userspace fuzzing test when a large size
allocation is made from ion
[<ffffffc00008a098>] show_stack+0x10/0x1c
[<ffffffc00119c390>] dump_stack+0x74/0xc8
[<ffffffc00020d9a0>] kasan_report_error+0x2b0/0x408
[<ffffffc00020dbd4>] kasan_report+0x34/0x40
[<ffffffc00020cfec>] __asan_storeN+0x15c/0x168
[<ffffffc00020d228>] memset+0x20/0x44
[<ffffffc00009b730>] __dma_alloc_coherent+0x114/0x18c
[<ffffffc00009c6e8>] __dma_alloc_noncoherent+0xbc/0x19c
[<ffffffc000c2b3e0>] ion_cma_allocate+0x178/0x2f0
[<ffffffc000c2b750>] ion_secure_cma_allocate+0xdc/0x190
[<ffffffc000c250dc>] ion_alloc+0x264/0xb88
[<ffffffc000c25e94>] ion_ioctl+0x1f4/0x480
[<ffffffc00022f650>] do_vfs_ioctl+0x67c/0x764
[<ffffffc00022f790>] SyS_ioctl+0x58/0x8c
Change-Id: Idc9c19977a8cc62c7d092f689d30368704b400bc
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
(cherry picked from commit 1f8f9b566e)
We should call ipxitf_put() if the copy_to_user() fails.
Reported-by: 李强 <liqiang6-s@360.cn>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Change-Id: Ib541c679cc5f4242713eb035aed458043b8ce97e
(cherry picked from commit ee0d8d8482345ff97a75a7d747efc309f13b0d80)
The default_normal option causes mounts with the gid set to
AID_SDCARD_RW to have user specific gids, as in the normal case.
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Change-Id: I9619b8ac55f41415df943484dc8db1ea986cef6f
Bug: 64672411
fsnotify_open is not called within dentry_open,
so we need to call it ourselves.
Change-Id: Ia7f323b3d615e6ca5574e114e8a5d7973fb4c119
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Bug: 70706497
... rather than relying on ciptool(8) never passing it anything else. Give
it e.g. an AF_UNIX connected socket (from socketpair(2)) and it'll oops,
trying to evaluate &l2cap_pi(sock->sk)->chan->dst...
Bug: 33982955
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Change-Id: I078260c1b5be6a96b54c265da0236bf84842e450
same story as cmtp
Bug: 33982955
Change-Id: I60ce3e3b5a5a0e41ddaec155a0c6a46307eedeb7
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
commit b3916db32c upstream.
We need to verify that the given sockets actually are l2cap sockets. If
they aren't, we are not supposed to access bt_sk(sock) and we shouldn't
start the session if the offsets turn out to be valid local BT addresses.
That is, if someone passes a TCP socket to HIDCONNADD, then we access some
random offset in the TCP socket (which isn't even guaranteed to be valid).
Fix this by checking that the socket is an l2cap socket.
Change-Id: I401bca741588b34876a1c835d8d4567852b4ec75
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
CONFIG_CC_OPTIMIZE_FOR_SIZE is set on modern android devices.
Originally this config was set with the assumption that smaller
code size would yield hot cache lines and faster code, however,
that's not the case today.
Signed-off-by: Wei Wang <wvw@google.com>
Change-Id: Ib127ede04e700650b97541d6cca16da659f45c69
Several build configurations had already disabled this warning because
it generates a lot of false positives. But some had not, and it was
still enabled for "allmodconfig" builds, for example.
Looking at the warnings produced, every single one I looked at was a
false positive, and the warnings are frequent enough (and big enough)
that they can easily hide real problems that you don't notice in the
noise generated by -Wmaybe-uninitialized.
The warning is good in theory, but this is a classic case of a warning
that causes more problems than the warning can solve.
If gcc gets better at avoiding false positives, we may be able to
re-enable this warning. But as is, we're better off without it, and I
want to be able to see the *real* warnings.
Change-Id: Ie810d255be8911c413c9abe6965a9a66639a1dce
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Running mmcqd as a prio 120 thread forces it to compete with standard
user processes for IO performance, especially when the system is under
severe CPU load. Move it to a SCHED_FIFO thread to reduce the impact of
load on IO performance.
bug 25392275
Change-Id: I1edfe73baa25e181367c30c1f40fee886e92b60d
Running dm-crypt in a standard workqueue results in IO competing for CPU
time with standard user apps, which can lead to pipeline bubbles and
seriously degraded performance. Move to a WQ_HIGHPRI workqueue to
protect against that.
bug 25392275
Change-Id: I589149a31c7b5d322fe2ed5b2476b1f6e3d5ee6f
Use unbound workqueue so that work is automatically ballanced between
available CPUs.
CRs-fixed: 670391
Change-Id: I169099d0b5b27535633c9d3aaab2037b5fea6aa9
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
[joonwoop@codeaurora.org: resolve trivial merge conflict]
Patch-mainline: dm-devel @ 04/05/14, 14:06
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
commit 321027c1fe77f892f4ea07846aeae08cefbbb290 upstream.
commit fe525a280e8b5f04c7666fe22d1a4ef592f7b953 in 3.16.40
bug: 37901413
Di Shen reported a race between two concurrent sys_perf_event_open()
calls where both try and move the same pre-existing software group
into a hardware context.
The problem is exactly that described in commit:
f63a8daa5812 ("perf: Fix event->ctx locking")
... where, while we wait for a ctx->mutex acquisition, the event->ctx
relation can have changed under us.
That very same commit failed to recognise sys_perf_event_context() as an
external access vector to the events and thereby didn't apply the
established locking rules correctly.
So while one sys_perf_event_open() call is stuck waiting on
mutex_lock_double(), the other (which owns said locks) moves the group
about. So by the time the former sys_perf_event_open() acquires the
locks, the context we've acquired is stale (and possibly dead).
Apply the established locking rules as per perf_event_ctx_lock_nested()
to the mutex_lock_double() for the 'move_group' case. This obviously means
we need to validate state after we acquire the locks.
Change-Id: I816a317dff3ce999c94d22b7e51152ad1dcc30a2
Reported-by: Di Shen (Keen Lab)
Tested-by: John Dias <joaodias@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Min Chong <mchong@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Fixes: f63a8daa5812 ("perf: Fix event->ctx locking")
Link: http://lkml.kernel.org/r/20170106131444.GZ3174@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
[bwh: Backported to 3.16:
- Use ACCESS_ONCE() instead of READ_ONCE()
- Test perf_event::group_flags instead of group_caps
- Add the err_locked cleanup block, which we didn't need before
- Adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
There have been a few reported issues wrt. the lack of locking around
changing event->ctx. This patch tries to address those.
It avoids the whole rwsem thing; and while it appears to work, please
give it some thought in review.
What I did fail at is sensible runtime checks on the use of
event->ctx, the RCU use makes it very hard.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/20150123125834.209535886@infradead.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
(cherry picked from commit f63a8daa5812afef4f06c962351687e1ff9ccb2b)
Bug: 30955111
Bug: 31095224
Change-Id: I8dfc0aae8d1206c177454e0093dacd82b6129c55
Signed-off-by: Joao Dias <joaodias@google.com>
Originally from Peter Zijlstra. The helper migrates perf events
from one cpu to another cpu.
Change-Id: I4d3c45b4594f3d26bbe7cc9e3fb79675ffac8b5e
Signed-off-by: Zheng Yan <zheng.z.yan@intel.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1339741902-8449-5-git-send-email-zheng.z.yan@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Allow the pmu->event_init callback to change event->cpu, so the PMU driver
can choose the CPU on which to install events.
Change-Id: Ie1f67c8b9fac650002f059081fe325eb799690c1
Signed-off-by: Zheng Yan <zheng.z.yan@intel.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1339741902-8449-4-git-send-email-zheng.z.yan@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
(cherry picked from commit 12ca6ad2e3a896256f086497a7c7406a547ee373)
There's a race on CPU unplug where we free the swevent hash array
while it can still have events on. This will result in a
use-after-free which is BAD.
Simply do not free the hash array on unplug. This leaves the thing
around and no use-after-free takes place.
When the last swevent dies, we do a for_each_possible_cpu() iteration
anyway to clean these up, at which time we'll free it, so no leakage
will occur.
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Tested-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Change-Id: I14c0679a2934dccdbb052805e6430fe54b5978f0
Bug: 30952077
Buffer overread may happen as nl80211_set_station() reads 4 bytes
from the attribute NL80211_ATTR_LOCAL_MESH_POWER_MODE without
validating the size of data received when userspace sends less
than 4 bytes of data with NL80211_ATTR_LOCAL_MESH_POWER_MODE.
Define nla_policy for NL80211_ATTR_LOCAL_MESH_POWER_MODE to avoid
the buffer overread.
Fixes: 3b1c5a5307 ("{cfg,nl}80211: mesh power mode primitives and userspace access")
Cc: stable@vger.kernel.org
Bug: 36819059
Signed-off-by: Srinivas Dasari <dasaris@qti.qualcomm.com>
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git
Git-commit: 8feb69c7bd89513be80eb19198d48f154b254021
Change-Id: Ie20993309501fd242782311b9fe787931f716116
CRs-Fixed: 2055013
Signed-off-by: Srinivas Dasari <dasaris@codeaurora.org>
nla policy checks for only maximum length of the attribute data
when the attribute type is NLA_BINARY. If userspace sends less
data than specified, the wireless drivers may access illegal
memory. When type is NLA_UNSPEC, nla policy check ensures that
userspace sends minimum specified length number of bytes.
Remove type assignment to NLA_BINARY from nla_policy of
NL80211_ATTR_PMKID to make this NLA_UNSPEC and to make sure minimum
WLAN_PMKID_LEN bytes are received from userspace with
NL80211_ATTR_PMKID.
Fixes: 67fbb16be6 ("nl80211: PMKSA caching support")
Cc: stable@vger.kernel.org
Bug: 36818836
Signed-off-by: Srinivas Dasari <dasaris@qti.qualcomm.com>
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git
Git-commit: 9361df14d1cbf966409d5d6f48bb334384fbe138
Change-Id: I5feb729a9ef48f67c4ee460e7e133d5fc8cecd4f
CRs-Fixed: 2061676
Signed-off-by: Srinivas Dasari <dasaris@codeaurora.org>
When the device descriptor is closed, the `substream->runtime` pointer
is freed. But another thread may be in the ioctl handler, case
SNDRV_CTL_IOCTL_PCM_INFO. This case calls snd_pcm_info_user() which
calls snd_pcm_info() which accesses the now freed `substream->runtime`.
Bug: 36006981
Signed-off-by: Robb Glasser <rglasser@google.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Change-Id: I445d24bc21dc0af6d9522a8daabe64969042236a
Fixes a steady memory leak in the keychord release code. A close of
the keychord device will leak 1 keychord structure. Easily
reproducible by a simple program that does an open()->write()->close()
of the keychord device.
Bug: 64483974
Change-Id: I1fa402c666cffb00b8cfd6379d9fe47a0989152c
Signed-off-by: Mohan Srinivasan <srmohan@google.com>
(cherry picked from commit 72a8dae2c25d0277e48672ee85b70236268add01)
There are multiple bugs caused by threads racing in keychord_write.
1) Threads racing through this function can cause the same element to
be added to a linked list twice (multiple calls to
input_register_handler() for the same input_handler struct). And the
races can also cause an element in a linked list that doesn't exist
attempted to be removed (multiple calls to input_unregister_handler()
with the same input_handler struct).
2) The races can also cause duplicate kfree's of the keychords
struct.
Bug: 64133562
Bug: 63974334
Change-Id: I6329a4d58c665fab5d3e96ef96391e07b4941e80
Signed-off-by: Mohan Srinivasan <srmohan@google.com>
(cherry picked from commit 59584701f1e2ce8ce024570576b206bea6ac69cf)
This was reported many times, and this was even mentioned in commit
52ee2dfdd4 "pids: refactor vnr/nr_ns helpers to make them safe" but
somehow nobody bothered to fix the obvious problem: task_tgid_nr_ns()
is not safe because task->group_leader points to nowhere after the
exiting task passes exit_notify(), rcu_read_lock() can not help.
We really need to change __unhash_process() to nullify group_leader,
parent, and real_parent, but this needs some cleanups. Until then we
can turn task_tgid_nr_ns() into another user of __task_pid_nr_ns() and
fix the problem.
Reported-by: Troy Kensinger <tkensinger@google.com>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
(url: https://patchwork.kernel.org/patch/9913055/)
Bug: 31495866
Change-Id: I5e67b02a77e805f71fa3a787249f13c1310f02e2
commit 4f0414e54e4d1893c6f08260693f8ef84c929293 upstream.
We need to load the TX SG list in sendmsg(2) after waiting for
incoming data, not before.
Bug: 64386293
Change-Id: Ibb0b7969ee1df314b49462ecd65ce381118d915d
Cc: stable@vger.kernel.org
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Tested-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Siqi Lin <siqilin@google.com>
The configs for this is used for Bluez.
So, there is no reason to keep this that causes the Security
Vulnerability.
Bug: 63527053
Change-Id: Ia25a8268412ce58c6a162953af3602634b219669
Signed-off-by: Ecco Park <eccopark@google.com>