Add support to early mount system partition so that system
modules can be loaded during early init for msm8226 and msm8974.
[haggertk:] Updated msm8974{,pro}/ as well so that {h,k}lte* pick
up this change.
Change-Id: I9d75bec6ff9bada5ab2db6de2a58e40323aa6ca2
Signed-off-by: Swetha Chikkaboraiah <schikk@codeaurora.org>
Signed-off-by: Nirmal Abraham <nabrah@codeaurora.org>
Signed-off-by: Bruno Martins <bgcngm@gmail.com>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
MDSS (2015) driver are fully compatible with S6E8AA0A panels now:
- added dsi_phy resource to dt to allow dsi controller to connect to physical display
- disabled mdp video pingpong for S6E8AA0A to avoid fps drops
- fixed (long) delay between splash screen and bootanimation
- fixed low brightness when calling MDSS_EVENT_PANEL_OFF at init
Change-Id: I7bac75be9fc63d3852fd9246aa66d3ca59d87617
Upon enabling the flashlight via sysfs or camera driver, the driver would not power down correctly,
leaving the led in a powered state but without any output but still drawing power.
Reverting this to a older release fixes the issue.
Change-Id: Ia7e5eec0fc9e51c8e71efc20b038499949c55381
This heavily decreases the timout value for stopping a process.
Therefore it enters deep-sleep much quicker which saves more battery.
Change-Id: I7e3c9f8d62354324b40a70aa1b999c0897ea0436
Samsung added this defconfig as default in the SM-G800H CRJ1 source
drop, however it seems to break correct rotation behaviour. In
particular if rotation is disabled and re-enabled after a while, it does
not work.
Disabling this restores the expected behaviour.
Unfortunately the Samsung Galaxy S III Neo panel driver does not play nicely
with newer mdss stack. In particular, once the system boots the phone
stays on Samsung logo and everything shifts to purple.
Since for now the only supported device is the Samsung Galaxy S III Neo,
switch to the mdss driver shipped in Samsung Galaxy S III Neo OSRC KK release.
We will switch back to the MM mdss stack once we figure out why it does not work.
https://github.com/LineageOS/android_kernel_motorola_msm8226 @ cm-14.1
This is needed because the stock driver which comes from OSRC requires
firmware loading. Using stock blobs for firmware loading however does
not work, so simply swich to this driver which does not require firmware
loading and just work with the aosp libfmjni
When comparing MAC hashes, AEAD authentication tags, or other hash
values in the context of authentication or integrity checking, it
is important not to leak timing information to a potential attacker,
i.e. when communication happens over a network.
Bytewise memory comparisons (such as memcmp) are usually optimized so
that they return a nonzero value as soon as a mismatch is found. E.g,
on x86_64/i5 for 512 bytes this can be ~50 cyc for a full mismatch
and up to ~850 cyc for a full match (cold). This early-return behavior
can leak timing information as a side channel, allowing an attacker to
iteratively guess the correct result.
This patch adds a new method crypto_memneq ("memory not equal to each
other") to the crypto API that compares memory areas of the same length
in roughly "constant time" (cache misses could change the timing, but
since they don't reveal information about the content of the strings
being compared, they are effectively benign). Iow, best and worst case
behaviour take the same amount of time to complete (in contrast to
memcmp).
Note that crypto_memneq (unlike memcmp) can only be used to test for
equality or inequality, NOT for lexicographical order. This, however,
is not an issue for its use-cases within the crypto API.
We tried to locate all of the places in the crypto API where memcmp was
being used for authentication or integrity checking, and convert them
over to crypto_memneq.
crypto_memneq is declared noinline, placed in its own source file,
and compiled with optimizations that might increase code size disabled
("Os") because a smart compiler (or LTO) might notice that the return
value is always compared against zero/nonzero, and might then
reintroduce the same early-return optimization that we are trying to
avoid.
Using #pragma or __attribute__ optimization annotations of the code
for disabling optimization was avoided as it seems to be considered
broken or unmaintained for long time in GCC [1]. Therefore, we work
around that by specifying the compile flag for memneq.o directly in
the Makefile. We found that this seems to be most appropriate.
As we use ("Os"), this patch also provides a loop-free "fast-path" for
frequently used 16 byte digests. Similarly to kernel library string
functions, leave an option for future even further optimized architecture
specific assembler implementations.
This was a joint work of James Yonan and Daniel Borkmann. Also thanks
for feedback from Florian Weimer on this and earlier proposals [2].
[1] http://gcc.gnu.org/ml/gcc/2012-07/msg00211.html
[2] https://lkml.org/lkml/2013/2/10/131
Change-Id: Ic56362242ad941c1bf1c1199ee5f7d05a2e144eb
Signed-off-by: James Yonan <james@openvpn.net>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Florian Weimer <fw@deneb.enyo.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
* Prior to S3NEO/android_kernel_samsung_msm8226/commit/87b76718941dda7bcdc74046e790e94393e520ec, we
set CONFIG_SEC_DEBUG for all defconfigs. By dropping that, we
inadvertently prevented the proper update of restart_reason when
attempting to perform a full boot from offmode charging, creating
the situation where the device had to be removed from power before
successfully booting-up from that state.
Fixes: 87b7671894 ("ARM: configs: lineage_*: Disable CONFIG_SEC_DEBUG")
Change-Id: I5864b5fef3df08108bb80cb591807f7a78c66666
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Prior to this change, we would decide whether to force scan a LRU during
reclaim if that LRU itself was too small for the current priority.
However, this can lead to the file LRU getting force scanned even if
there are a lot of anonymous pages we can reclaim, leading to hot file
pages getting needlessly reclaimed.
To address this, we instead only force scan when none of the reclaimable
LRUs are big enough.
Gives huge improvements with zswap. For example, when doing -j20 kernel
build in a 500MB container with zswap enabled, runtime (in seconds) is
greatly reduced:
x without this change
+ with this change
N Min Max Median Avg Stddev
x 5 700.997 790.076 763.928 754.05 39.59493
+ 5 141.634 197.899 155.706 161.9 21.270224
Difference at 95.0% confidence
-592.15 +/- 46.3521
-78.5293% +/- 6.14709%
(Student's t, pooled s = 31.7819)
Should also give some improvements in regular (non-zswap) swap cases.
Yes, hughd found significant speedup using regular swap, with several
memcgs under pressure; and it should also be effective in the non-memcg
case, whenever one or another zone LRU is forced too small.
Change-Id: I1c580ee7c73239781afe8967f43abb1b3e247a0f
Signed-off-by: Suleiman Souhlal <suleiman@google.com>
Signed-off-by: Hugh Dickins <hughd@google.com>
Cc: Suleiman Souhlal <suleiman@google.com>
Cc: Mel Gorman <mgorman@suse.de>
Acked-by: Rik van Riel <riel@redhat.com>
Acked-by: Rafael Aquini <aquini@redhat.com>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Bob Liu <bob.liu@oracle.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Luigi Semenzato <semenzato@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[ Upstream commit 29b00e609960ae0fcff382f4c7079dd0874a5311 ]
When we made the shmem_reserve_inode call in shmem_link conditional, we
forgot to update the declaration for ret so that it always has a known
value. Dan Carpenter pointed out this deficiency in the original patch.
[aviraxp: Adjust context for 3.10]
Fixes: 1062af920c07 ("tmpfs: fix link accounting when a tmpfile is linked in")
Change-Id: Ib91581d0f1ffbfb1ebe2f827aa125684a844eded
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Hugh Dickins <hughd@google.com>
Cc: Matej Kupljen <matej.kupljen@gmail.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 1062af920c07f5b54cf5060fde3339da6df0cf6b ]
tmpfs has a peculiarity of accounting hard links as if they were
separate inodes: so that when the number of inodes is limited, as it is
by default, a user cannot soak up an unlimited amount of unreclaimable
dcache memory just by repeatedly linking a file.
But when v3.11 added O_TMPFILE, and the ability to use linkat() on the
fd, we missed accommodating this new case in tmpfs: "df -i" shows that
an extra "inode" remains accounted after the file is unlinked and the fd
closed and the actual inode evicted. If a user repeatedly links
tmpfiles into a tmpfs, the limit will be hit (ENOSPC) even after they
are deleted.
Just skip the extra reservation from shmem_link() in this case: there's
a sense in which this first link of a tmpfile is then cheaper than a
hard link of another file, but the accounting works out, and there's
still good limiting, so no need to do anything more complicated.
Change-Id: I6ecd21a4457a8360c85e9033b79323a6563de7db
Link: http://lkml.kernel.org/r/alpine.LSU.2.11.1902182134370.7035@eggly.anvils
Fixes: f4e0c30c191 ("allow the temp files created by open() to be linked to")
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Hugh Dickins <hughd@google.com>
Reported-by: Matej Kupljen <matej.kupljen@gmail.com>
Acked-by: 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: Sasha Levin <sashal@kernel.org>
Channel_mapping array size varies for different commands.
Add check for num_channels before calling q6asm_map_channels.
Bug: 129851238
Change-Id: Iccbcfe82f716fc0ffe0a26b1779dcaa1c3cb805b
Signed-off-by: Rohit kumar <rohitkr@codeaurora.org>
[haggertk: Backport to 3.4/msm8974]
CVE-2019-2328
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Token from DSP might be invalid for array index. Validate the
token before being used as array index.
Bug: 129850483
Change-Id: I9f47e1328d75d9f9acf7e85ddb452019b6eced0a
Signed-off-by: Xiaojun Sang <xsang@codeaurora.org>
Signed-off-by: Siqi Lin <siqilin@google.com>
[haggertk: Backport to 3.4/msm8974]
CVE-2019-2326
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Verify that user applications are not using the kernel RPC message
handle to restrict them from directly attaching to guest OS on the
remote subsystem.
Bug: 129852114
Change-Id: Icfa114a12f2bebbe815eb9930027fded51f717fd
Acked-by: Thyagarajan Venkatanarayanan <venkatan@qti.qualcomm.com>
Signed-off-by: Tharun Kumar Merugu <mtharu@codeaurora.org>
Signed-off-by: Mohammed Nayeem Ur Rahman <mohara@codeaurora.org>
[haggertk: Backport to 3.4/msm8974]
CVE-2019-2308
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
commit b6653b3629e5b88202be3c9abc44713973f5c4b4 upstream.
tcp_fragment() might be called for skbs in the write queue.
Memory limits might have been exceeded because tcp_sendmsg() only
checks limits at full skb (64KB) boundaries.
Therefore, we need to make sure tcp_fragment() wont punish applications
that might have setup very low SO_SNDBUF values.
Fixes: f070ef2ac667 ("tcp: tcp_fragment() should apply sane memory limits")
Change-Id: I4194f72d473c236b02ed2d270c1af3e004ba46b7
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Christoph Paasch <cpaasch@apple.com>
Tested-by: Christoph Paasch <cpaasch@apple.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
This is partly a backport of d6c0a4f60984
(ipv4: Kill 'rt_src' from 'struct rtable').
skb->sk can be null, and in fact it is when creating the buffer
in inet_rtm_getroute. There is no other way of accessing the flow,
so pass it directly.
Fixes invalid memory address when running 'ip route get $IPADDR'
Bug: https://gitlab.com/LineageOS/issues/android/issues/492
Change-Id: I7b9e5499614b96360c9c8420907e82e145bb97f3
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
commit 134fca9063ad4851de767d1768180e5dede9a881 upstream.
The semantics of what mincore() considers to be resident is not
completely clear, but Linux has always (since 2.3.52, which is when
mincore() was initially done) treated it as "page is available in page
cache".
That's potentially a problem, as that [in]directly exposes
meta-information about pagecache / memory mapping state even about
memory not strictly belonging to the process executing the syscall,
opening possibilities for sidechannel attacks.
Change the semantics of mincore() so that it only reveals pagecache
information for non-anonymous mappings that belog to files that the
calling process could (if it tried to) successfully open for writing;
otherwise we'd be including shared non-exclusive mappings, which
- is the sidechannel
- is not the usecase for mincore(), as that's primarily used for data,
not (shared) text
[jkosina@suse.cz: v2]
Link: http://lkml.kernel.org/r/20190312141708.6652-2-vbabka@suse.cz
[mhocko@suse.com: restructure can_do_mincore() conditions]
Link: http://lkml.kernel.org/r/nycvar.YFH.7.76.1903062342020.19912@cbobk.fhfr.pm
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Josh Snyder <joshs@netflix.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Originally-by: Linus Torvalds <torvalds@linux-foundation.org>
Originally-by: Dominique Martinet <asmadeus@codewreck.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Kevin Easton <kevin@guarana.org>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Cyril Hrubis <chrubis@suse.cz>
Cc: Tejun Heo <tj@kernel.org>
Cc: Kirill A. Shutemov <kirill@shutemov.name>
Cc: Daniel Gruss <daniel@gruss.cc>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
CVE-2019-5489
[haggertk: Backport to 3.4 - open code file_inode()]
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: I84459dea04113d5468c00d2ef46b64735f654697
commit b5330628546616af14ff23075fbf8d4ad91f6e25 upstream.
special_mapping_fault() is absolutely broken. It seems it was always
wrong, but this didn't matter until vdso/vvar started to use more than
one page.
And after this change vma_is_anonymous() becomes really trivial, it
simply checks vm_ops == NULL. However, I do think the helper makes
sense. There are a lot of ->vm_ops != NULL checks, the helper makes the
caller's code more understandable (self-documented) and this is more
grep-friendly.
This patch (of 3):
Preparation. Add the new simple helper, vma_is_anonymous(vma), and change
handle_pte_fault() to use it. It will have more users.
The name is not accurate, say a hpet_mmap()'ed vma is not anonymous.
Perhaps it should be named vma_has_fault() instead. But it matches the
logic in mmap.c/memory.c (see next changes). "True" just means that a
page fault will use do_anonymous_page().
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Hugh Dickins <hughd@google.com>
Cc: Pavel Emelyanov <xemul@parallels.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[bwh: Backported to 3.16 as dependency of "mm/mincore.c: make mincore() more
conservative"; adjusted context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
CVE-2019-5489
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: I179b12b1f76810b4ca08480c03b4b0e0985fe45e
commit a1616a5ac99ede5d605047a9012481ce7ff18b16 upstream.
Struct ca is copied from userspace. It is not checked whether the "name"
field is NULL terminated, which allows local users to obtain potentially
sensitive information from kernel stack memory, via a HIDPCONNADD command.
This vulnerability is similar to CVE-2011-1079.
Signed-off-by: Young Xiao <YangX92@hotmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
CVE-2019-11884
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: If26bd0108596f42bb48349146f0c84eb0a675276
commit 592acbf16821288ecdc4192c47e3774a4c48bb64 upstream.
This commit zeroes out the unused memory region in the buffer_head
corresponding to the extent metablock after writing the extent header
and the corresponding extent node entries.
This is done to prevent random uninitialized data from getting into
the filesystem when the extent block is synced.
This fixes CVE-2019-11833.
Signed-off-by: Sriram Rajagopalan <sriramr@arista.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: Ie670aab0f8f039ba6a1b258efe1ae440e0f544d9
Francescodario Cuzzocrea
Swetha Chikkaboraiah
xXPR0T0TYPEXx
pythonlimited
Ethan Chen
James Yonan
darkness19
Y-T-G
Suleiman Souhlal
Darrick J. Wong
Rohit kumar
Xiaojun Sang
Tharun Kumar Merugu
Eric Dumazet
Luca Weiss
Jiri Kosina
Oleg Nesterov
Young Xiao
Sriram Rajagopalan