A set of processes may happen to perform interleaved reads, i.e.,requests
whose union would give rise to a sequential read pattern. There are two
typical cases: in the first case, processes read fixed-size chunks of
data at a fixed distance from each other, while in the second case processes
may read variable-size chunks at variable distances. The latter case occurs
for example with QEMU, which splits the I/O generated by the guest into
multiple chunks, and lets these chunks be served by a pool of cooperating
processes, iteratively assigning the next chunk of I/O to the first
available process. CFQ uses actual queue merging for the first type of
rocesses, whereas it uses preemption to get a sequential read pattern out
of the read requests performed by the second type of processes. In the end
it uses two different mechanisms to achieve the same goal: boosting the
throughput with interleaved I/O.
This patch introduces Early Queue Merge (EQM), a unified mechanism to get a
sequential read pattern with both types of processes. The main idea is
checking newly arrived requests against the next request of the active queue
both in case of actual request insert and in case of request merge. By doing
so, both the types of processes can be handled by just merging their queues.
EQM is then simpler and more compact than the pair of mechanisms used in
CFQ.
Finally, EQM also preserves the typical low-latency properties of BFQ, by
properly restoring the weight-raising state of a queue when it gets back to
a non-merged state.
Change-Id: If95ed48806330667f26959006a20ad13abfd44be
Signed-off-by: Mauro Andreolini <mauro.andreolini@unimore.it>
Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Add the BFQ-v7r8 I/O scheduler to 3.4.
The general structure is borrowed from CFQ, as much of the code for
handling I/O contexts. Over time, several useful features have been
ported from CFQ as well (details in the changelog in README.BFQ). A
(bfq_)queue is associated to each task doing I/O on a device, and each
time a scheduling decision has to be made a queue is selected and served
until it expires.
- Slices are given in the service domain: tasks are assigned
budgets, measured in number of sectors. Once got the disk, a task
must however consume its assigned budget within a configurable
maximum time (by default, the maximum possible value of the
budgets is automatically computed to comply with this timeout).
This allows the desired latency vs "throughput boosting" tradeoff
to be set.
- Budgets are scheduled according to a variant of WF2Q+, implemented
using an augmented rb-tree to take eligibility into account while
preserving an O(log N) overall complexity.
- A low-latency tunable is provided; if enabled, both interactive
and soft real-time applications are guaranteed a very low latency.
- Latency guarantees are preserved also in the presence of NCQ.
- Also with flash-based devices, a high throughput is achieved
while still preserving latency guarantees.
- BFQ features Early Queue Merge (EQM), a sort of fusion of the
cooperating-queue-merging and the preemption mechanisms present
in CFQ. EQM is in fact a unified mechanism that tries to get a
sequential read pattern, and hence a high throughput, with any
set of processes performing interleaved I/O over a contiguous
sequence of sectors.
- BFQ supports full hierarchical scheduling, exporting a cgroups
interface. Since each node has a full scheduler, each group can
be assigned its own weight.
- If the cgroups interface is not used, only I/O priorities can be
assigned to processes, with ioprio values mapped to weights
with the relation weight = IOPRIO_BE_NR - ioprio.
- ioprio classes are served in strict priority order, i.e., lower
priority queues are not served as long as there are higher
priority queues. Among queues in the same class the bandwidth is
distributed in proportion to the weight of each queue. A very
thin extra bandwidth is however guaranteed to the Idle class, to
prevent it from starving.
Change-Id: I1603a3f5cdbaca85d8494a396be7daf932a754b3
Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Update Kconfig.iosched and do the related Makefile changes to include
kernel configuration options for BFQ. Also add the bfqio controller
to the cgroups subsystem.
Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>
Change-Id: I58d05e292ee338400601336797aefb82f9638cf9
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Bug: 63245673
Change-Id: I5fc596420301045895e5a9a7e297fd05434babf9
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
This moves the code to adjust the gid/uid of lower filesystem
files under the mount flag derive_gid.
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Change-Id: I44eaad4ef67c7fcfda3b6ea3502afab94442610c
Bug: 63245673
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Fix double free on error paths
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Change-Id: I1c25a175e87e5dd5cafcdcf9d78bf4c0dc3f88ef
Bug: 65386954
Fixes: aa6d3ace42f9 ("mnt: Add filesystem private data to mount points")
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
found some case that IOVAR callers set response buffer not enough to
contain input command string + argument. so it finally fail in IOVAR
transaction by its shorter buffer length.
proposed fix is taking care this case by providing enough local
buffer inside dhd_iovar, which enough to input/output.
[backported to manta: Corinna Vinschen <xda@vinschen.de>]
Signed-off-by: Insun Song <insun.song@broadcom.com>
Signed-off-by: Corinna Vinschen <xda@vinschen.de>
Bug: 36000515
Change-Id: I0afedcc29b05b12f42ebc619e6feeaa868fc00de
CVE-2017-0633
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
This separates the kref for ion handles into two components.
Userspace requests through the ioctl will hold at most one
reference to the internally used kref. All additional requests
will increment a separate counter, and the original reference is
only put once that counter hits 0. This protects the kernel from
a poorly behaving userspace.
Bug: 34276203
Change-Id: Ibc36bc4405788ed0fea7337b541cad3be2b934c0
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Git-repo: https://android.googlesource.com/kernel/msm/
Git-commit: 20abfcc16884a5af973a5e91dd013ddd789c44f4
[d-cagle@codeaurora.org: Resolve style issues]
Signed-off-by: Dennis Cagle <d-cagle@codeaurora.org>
CVE-2017-0564
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
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
Bug: 38195738
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
Signed-off-by: Maggie White <maggiewhite@google.com>
Change-Id: I6b1a0a3eaec10500cd4e73290efad4023bc83da5
CVE-2017-9725
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Disable and remove gud mobicore driver.
Bug: 33842910
CRs-Fixed: 1116560
Change-Id: Ia16bc3e1331f86724a391fd367587b56ccc14546
Acked-by: Tony Hamilton <tonyh@qti.qualcomm.com>
Signed-off-by: Trudy Shearer <tshearer@codeaurora.org>
Signed-off-by: Dennis Cagle <d-cagle@codeaurora.org>
CVE-2017-9691
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Complete removal of gud mobicore driver.
The driver author delivers an updated version of the driver to
interested parties directly rendering this version obsolete.
Bug: 33842910
CRs-Fixed: 1116560
Change-Id: I40498d3203b1d6ca04f2b5a2e65461851d84d2d4
Acked-by: Tony Hamilton <tonyh@qti.qualcomm.com>
Signed-off-by: Trudy Shearer <tshearer@codeaurora.org>
Signed-off-by: Dennis Cagle <d-cagle@codeaurora.org>
Signed-off-by: Maggie White <maggiewhite@google.com>
CVE-2017-9691
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Assume that there are two threads, thread1 is setting
value of _rndis_qc variable in rndis_qc_bind_config_vendor
function. Thread2 jumps in and get the value of _rndis_qc
in rndis_qc_open_dev function before it is freed in
rndis_qc_bind_config_vendor function, since rndis_ipa_init
or usb_add_function failed. Use-after-free will happen as
Thread2 is referencing freed objects. To prevent this
spinlock is used where ever it is needed to protect
_rndis_qc variable.
Bug: 35136547
Change-Id: Ib45ae14281821eeaf79419e8d177cb5d51b94df8
CVE-2017-9684
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
RNDIS control path completion handlers are getting called during
disconnect as part of composition switch and this is leading to a
crash. Avoid this crash, by checking, if cdev is not NULL before
accessing.
CRs-Fixed: 717035
Bug: 35136547
Change-Id: Id8748f963298129a403ffd6e4413476013315061
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
CVE-2017-9684
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>
CVE-2017-9676
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Verify that the length of the socket buffer is sufficient to cover the
nlmsghdr structure before accessing the nlh->nlmsg_len field for further
input sanitization. If the client only supplies 1-3 bytes of data in
sk_buff, then nlh->nlmsg_len remains partially uninitialized and
contains leftover memory from the corresponding kernel allocation.
Operating on such data may result in indeterminate evaluation of the
nlmsg_len < sizeof(*nlh) expression.
The bug was discovered by a runtime instrumentation designed to detect
use of uninitialized memory in the kernel. The patch prevents this and
other similar tools (e.g. KMSAN) from flagging this behavior in the future.
Change-Id: I75991afbc07f14d6b0518db4e6042ee91e89907c
Signed-off-by: Mateusz Jurczyk <mjurczyk@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Before the patch, the flock flag could remain uninitialized for the
lifespan of the fuse_file allocation. Unless set to true in
fuse_file_flock(), it would remain in an indeterminate state until read in
an if statement in fuse_release_common(). This could consequently lead to
taking an unexpected branch in the code.
The bug was discovered by a runtime instrumentation designed to detect use
of uninitialized memory in the kernel.
Change-Id: Ifcdbf97b5feb73009c4cd152a5f32bd9cce3d3d6
Signed-off-by: Mateusz Jurczyk <mjurczyk@google.com>
Fixes: 37fb3a30b4 ("fuse: fix flock")
Cc: <stable@vger.kernel.org> # v3.1+
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Verify that the caller-provided sockaddr structure is large enough to
contain the sa_family field, before accessing it in bind() and connect()
handlers of the AF_UNIX socket. Since neither syscall enforces a minimum
size of the corresponding memory region, very short sockaddrs (zero or
one byte long) result in operating on uninitialized memory while
referencing .sa_family.
Change-Id: Ifa18852cf4380eac682bd3a533abf6a512b5ec47
Signed-off-by: Mateusz Jurczyk <mjurczyk@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Verify that the caller-provided sockaddr structure is large enough to
contain the sa_family field, before accessing it in the connect()
handler of the AF_CAIF socket. Since the syscall doesn't enforce a minimum
size of the corresponding memory region, very short sockaddrs (zero or one
byte long) result in operating on uninitialized memory while referencing
sa_family.
Change-Id: I19e8282cf2d2acf418d69f2380b319203fd23a84
Signed-off-by: Mateusz Jurczyk <mjurczyk@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Fix the sockaddr length verification in the connect() handler of NFC/LLCP
sockets, to compare against the size of the actual structure expected on
input (sockaddr_nfc_llcp) instead of its shorter version (sockaddr_nfc).
Both structures are defined in include/uapi/linux/nfc.h. The fields
specific to the _llcp extended struct are as follows:
276 __u8 dsap; /* Destination SAP, if known */
277 __u8 ssap; /* Source SAP to be bound to */
278 char service_name[NFC_LLCP_MAX_SERVICE_NAME]; /* Service name URI */;
279 size_t service_name_len;
If the caller doesn't provide a sufficiently long sockaddr buffer, these
fields remain uninitialized (and they currently originate from the stack
frame of the top-level sys_connect handler). They are then copied by
llcp_sock_connect() into internal storage (nfc_llcp_sock structure), and
could be subsequently read back through the user-mode getsockname()
function (handled by llcp_sock_getname()). This would result in the
disclosure of up to ~70 uninitialized bytes from the kernel stack to
user-mode clients capable of creating AFC_NFC sockets.
Change-Id: I56398a2edac9496001d1f96b4e625b55ca0b9934
Signed-off-by: Mateusz Jurczyk <mjurczyk@google.com>
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Check that the NFC_ATTR_TARGET_INDEX and NFC_ATTR_PROTOCOLS attributes (in
addition to NFC_ATTR_DEVICE_INDEX) are provided by the netlink client
prior to accessing them. This prevents potential unhandled NULL pointer
dereference exceptions which can be triggered by malicious user-mode
programs, if they omit one or both of these attributes.
Change-Id: I15f4f761cb8188cde901d66fb348513fdfbf3c09
Signed-off-by: Mateusz Jurczyk <mjurczyk@google.com>
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Verify that the caller-provided sockaddr structure is large enough to
contain the sa_family field, before accessing it in bind() handlers of the
AF_NFC socket. Since the syscall doesn't enforce a minimum size of the
corresponding memory region, very short sockaddrs (zero or one byte long)
result in operating on uninitialized memory while referencing .sa_family.
Change-Id: I634b4ad8cdd273afcb10955cf608ae84117c2a37
Signed-off-by: Mateusz Jurczyk <mjurczyk@google.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Verify that the caller-provided sockaddr structure is large enough to
contain the sa_family field, before accessing it in bind() and connect()
handlers of the AF_IUCV socket. Since neither syscall enforces a minimum
size of the corresponding memory region, very short sockaddrs (zero or
one byte long) result in operating on uninitialized memory while
referencing .sa_family.
Change-Id: Ia152d4c51a13705c6a41a0b2456a156d838acc86
Fixes: 52a82e23b9f2 ("af_iucv: Validate socket address length in iucv_sock_bind()")
Signed-off-by: Mateusz Jurczyk <mjurczyk@google.com>
[jwi: removed unneeded null-check for addr]
Signed-off-by: Julian Wiedmann <jwi@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Verify that the caller-provided sockaddr structure is large enough to
contain the sa_family field, before accessing it in bind() and connect()
handlers of the Bluetooth sockets. Since neither syscall enforces a minimum
size of the corresponding memory region, very short sockaddrs (zero or one
byte long) result in operating on uninitialized memory while referencing
sa_family.
Change-Id: I3c3bf3c9fa16abfb65f41e55c89c1ffcce2f58e7
Signed-off-by: Mateusz Jurczyk <mjurczyk@google.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Prevent use of uninitialized memory (originating from the stack frame of
do_sysctl()) by verifying that the name array is filled with sufficient
input data before comparing its specific entries with integer constants.
Through timing measurement or analyzing the kernel debug logs, a
user-mode program could potentially infer the results of comparisons
against the uninitialized memory, and acquire some (very limited)
information about the state of the kernel stack. The change also
eliminates possible future warnings by tools such as KMSAN and other
code checkers / instrumentations.
Change-Id: I44af72c8ffe080593a0f2cd88b3a1c93fb661e07
Link: http://lkml.kernel.org/r/20170524122139.21333-1-mjurczyk@google.com
Signed-off-by: Mateusz Jurczyk <mjurczyk@google.com>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Matthew Whitehead <tedheadster@gmail.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Alexander Potapenko <glider@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: Ic37926b0902bd4b850b070c8fceea8f328cd7b0d
(cherry picked from commit 0c3c934cc579c315c77ab37d64cfb33aed242046)
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
lowmemorykiller was not taking into account unevictable pages when
deciding what level to kill. If significant amounts of memory were
pinned, this caused lowmemorykiller to effectively stop at a much higher
level than it should.
BUG 31255977
Change-Id: I763ecbfef8c56d65bb8f6147ae810692bd81b6e2
(cherry picked from commit 91851d68006132c60fe0d05972892ea4fac704e4)
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Set TIF_MEMDIE tsk_thread flag before send kill signal to the
selected thread. This is to fit a usual code sequence and avoid
potential race issue.
Change-Id: I3eb66712ff349048834e06efbfb2ed5a0bb7463f
Signed-off-by: Weijie Yang <weijie.yang@samsung.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Zdrowy Gosciu <ZdrowyGosciu+GITHUB@gmail.com>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
In vmpressure notifier of LMK, shift_adj would have been set
by a previous invocation of notifier, which is not followed by
a lowmem_shrink yet. Since vmpressure has improved, reset
shift_adj to avoid false adaptive LMK trigger.
Change-Id: I2d77103d7c8f4d8a66e4652cba78e619a7bcef9a
Signed-off-by: Vinayak Menon <vinmenon@codeaurora.org>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
There were issues reported, where page cache thrashing was
observed because of LMK not killing tasks when required,
resulting in sluggishness and higher app launch latency.
LMK does not kill a task for the following reasons.
1. The free and file pages are above the LMK thresholds
2. LMK tries to pick task with an adj level corresponding
to current thresholds, but fails to do so because of the
absence of tasks in that level.
But sometimes it is better to kill a lower adj task, than thrashing.
And there are cases where the number of file pages are huge, though
we dont thrash, the reclaim process becomes time consuming, since
LMK triggers will be delayed because of higher number of file
pages. Even in such cases, when reclaim path finds it difficult
to reclaim pages, it is better to trigger lmk to free up some memory
faster.
The basic idea here is to make LMK more aggressive dynamically
when such a thrashing scenario is detected.
To detect thrashing, this patch uses vmpressure events.
The values of vmpressure upon which an action has to be taken,
was derived empirically.
This patch also adds tracepoints to validate this feature,
almk_shrink and almk_vmpressure.
Two knobs are available for the user to tune adaptive lmk
behaviour.
/sys/module/lowmemorykiller/parameters/adaptive_lmk - Write
1 to enable the feature, 0 to disable. By default disabled.
/sys/module/lowmemorykiller/parameters/vmpressure_file_min -
This parameter controls the behaviour of LMK when vmpressure
is in the range of 90-94. Adaptive lmk triggers based on number file
pages wrt vmpressure_file_min, when vmpressure is in the range of
90-94. Usually this is a pseudo minfree value, higher than the
highest configured value in minfree array.
Change-Id: I1a08160c35d3e33bdfd1d2c789c288fc07d0f0d3
Signed-off-by: Vinayak Menon <vinmenon@codeaurora.org>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Pointer other_free is getting dereferenced without
performing proper NULL checks which may cause issue.
Do proper NULL checks at all points before dereferencing
it.
Change-Id: I88515703d64730e42598ab16136dcce4c18b099c
Signed-off-by: Susheel Khiani <skhiani@codeaurora.org>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
When the lowmemory killer starts killing processes, it's useful to
be able to see the state of other memory in the system. Call the
lowmemory notifier to get other clients to dump out their state.
Change-Id: Ie3b1d47149f0108b42b7961fd47a8cc5efe2c590
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
There are many drivers in the kernel which can hold on
to lots of memory. It can be useful to dump out all those
drivers at key points in the kernel. Introduct a notifier
framework for dumping this information. When the notifiers
are called, drivers can dump out the state of any memory
they may be using.
Change-Id: I514ef1d01510a50970a661c8e9bedc8b78683eab
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Currently, vmpressure is tied to memcg and its events are
available only to userspace clients. This patch removes
the dependency on CONFIG_MEMCG and adds a mechanism for
in-kernel clients to subscribe for vmpressure events (in
fact raw vmpressure values are delivered instead of vmpressure
levels, to provide clients more flexibility to take actions
on custom pressure levels which are not currently defined
by vmpressure module).
Change-Id: I38010f166546e8d7f12f5f355b5dbfd6ba04d587
Signed-off-by: Vinayak Menon <vinmenon@codeaurora.org>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Leaks from the slab allocator are a very common cause of
out of memory issues and excessive lowmemorykiller killing.
Dump out the slab statistics as well to help with debugging.
Change-Id: Ia5e4eeb66092c76f2b761321c88fa75c4138927c
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Add extra debug information to make it easier to both determine
why the lowmemorykiller killed a process and to help find the source
of memory leaks.
Also increase the debug level for "select" statements to help prevent
flooding the log.
Change-Id: I3b6876c5ecdf192ecc271aed3f37579f66d47a08
Signed-off-by: Liam Mark <lmark@codeaurora.org>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Allow other functions to dump the list of tasks.
Useful for when debugging memory leaks.
Bug: 17871993
Change-Id: I76c33a118a9765b4c2276e8c76de36399c78dbf6
Signed-off-by: Liam Mark <lmark@codeaurora.org>
Signed-off-by: Naveen Ramaraj <nramaraj@codeaurora.org>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Couple of cases were reported few months ago, where the cpu was blocked
on the following call stack for /seconds/ after which the watchdog fires.
test_task_flag(p = 0xE14ABF00, ?)
lowmem_shrink(?, sc = 0xD7A03C04)
shrink_slab(shrink = 0xD7A03C04, nr_pages_scanned = 0, lru_pages = 120)
try_to_free_pages(zonelist = 0xC1116440, ?, ?, ?)
__alloc_pages_nodemask(?, order = 0, ?, nodemask = 0x0)
__do_page_cache_readahead(mapping = 0xEB819364, filp = 0xCC16DC00, offset =
ra_submit(?, ?, ?)
filemap_fault(vma = 0xC105D240, vmf = 0xD7A03DC8)
There weren't any dumps to analyse the case, but this can be a possible
reason. while_each_thread is known to be buggy and can result in the
function looping forever if the task exits, even when protected with
rcu_read_lock. Use for_each_thread instead.
More details on the problems with while_each_thread can be found
at https://lkml.org/lkml/2013/12/2/320
Change-Id: I5eb6e4b463f81142a2a7824db389201357432ec7
Signed-off-by: Vinayak Menon <vinmenon@codeaurora.org>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
The lowmem_shrink function discounts all the swap cache pages from
the file cache count. The zone aware code also discounts all file
cache pages from a certain zone. This results in some swap cache
pages being discounted twice, which can result in the low memory
killer being unnecessarily aggressive.
Fix the low memory killer to only discount the swap cache pages
once.
Change-Id: I650bbfbf0fbbabd01d82bdb3502b57ff59c3e14f
Signed-off-by: Liam Mark <lmark@codeaurora.org>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Currenlty most memory reclaim is done through kswapd.
Since kswapd uses a gfp mask of GFP_KERNEL, and because
the lowmemorykiller is zone aware, the lowmemorykiller will
ignore highmem most of the time.
This results in the lowmemorykiller being overly aggressive.
The fix to this issue is to allow the lowmemorykiller to
count highmem when being called by the kswapd if the lowmem
watermarks are satisfied.
Change-Id: I938644584f374763d10d429d835e74daa4854a38
Signed-off-by: Liam Mark <lmark@codeaurora.org>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Validate the output buffer length for L2CAP config requests and responses
to avoid overflowing the stack buffer used for building the option blocks.
Change-Id: I7a0ff0b9dd0156c0e6383214a9c86e4ec4c0d236
Cc: stable@vger.kernel.org
Signed-off-by: Ben Seri <ben@armis.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
CVE-2017-1000251
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
There is no bound check in stream_cfg_cmd->num_streams and it's used in
several places as a maximum index into the stream_cfg_cmd->stream_handle
array which has a size of 15. Current code didn't check the maximum
index to make sure it didn't exceed the array size.
Bug: 62379525
Change-Id: Idcf639486d235551882dafc34d9e798d78c70bf0
Signed-off-by: Maggie White <maggiewhite@google.com>
CVE-2017-8251
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
In msm_isp_get_bufq, if bufq_index equals buf_mgr->num_buf_q,
it will pass the check, leading to off-by-one overflow
(exceed the length of array by one element).
CRs-Fixed: 2031677
Bug: 36136563
Change-Id: I7ea465897e2c37de6ca0155c3e225f1444b3cf13
Signed-off-by: Gaoxiang Chen <gaochen@codeaurora.org>
CVE-2017-11000
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Userspace can call some ioctls with 0 value for bufq_handle which is
currently can bypass checks in msm_isp_get_bufq and will result in
using uninitialized bufq structure, even though 0 is not a legitimate
value for bufq_handle. This change adds a check to prevent this
behaviour and to return error in case it happens.
Change-Id: I6422ec82671080cfa62fc43026b6cc33261cf11c
Signed-off-by: Petar Sivenov <psiven@codeaurora.org>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
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
Bug: 38195131
Change-Id: Ib527a380a857719bff8254be514133528bd64c75
CVE-2017-10998
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
added boundary check for input parameters not to corrupt kernel heap in
case user injected malformed input
Signed-off-by: Insun Song <insun.song@broadcom.com>
Bug: 37306719
Change-Id: I6dc12e9bcfce8f3b43ecf14bfd6976bf87afeaa5
CVE-2017-0791
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
WLC_E_ESCAN_RESULT event could be manipulated especially two length field
inside, one is for escan_result buffer length and another one is
bss_info length, the forged fields may bypass current length check and
corrupt kernel heap memory.
so added checking validation for two length fields in WLC_E_ESCAN_RESULT
event.
Signed-off-by: Insun Song <insun.song@broadcom.com>
Bug: 37351060
Change-Id: I31e9fccc48fc06278fb3a87a76ef7337296c2b0d
CVE-2017-0786
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Makesure the number of buffers count is less than
the maximum limit to avoid structure overflow errors.
Change-Id: Icf3850de36325637ae43ac95f1c8f0f63e201d31
CRs-fixed: 563694
Signed-off-by: Pachika, Vikas Reddy <vpachi@codeaurora.org>
[haggertk]: Note partial commit due to Samsung removing the define
in their code drop.
CVE-2014-9778
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Diogo Ferreira
Mauro Andreolini
Paolo Valente
Arianna Avanzini
Daniel Rosenberg
Insun Song
Maggie White
Dennis Cagle
Lena Salman
Kevin F. Haggerty
Mayank Rana
lianwei.wang
Mateusz Jurczyk
myfluxi
Tim Murray
Weijie Yang
Vinayak Menon
Susheel Khiani
Laura Abbott
Liam Mark
Ben Seri
Gaoxiang Chen
Petar Sivenov
Siena Richard
Pachika, Vikas Reddy