Add support for clocks CLOCK_REALTIME_ALARM and CLOCK_BOOTTIME_ALARM.
Change-Id: Iafc8445d3d7ffb35110c860f1607bf03f1edb895
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Add the rtc irq support for alarmtimer to wakeup the
alarm during system suspend.
Change-Id: I41b774ed4e788359321e1c6a564551cc9cd40c8e
Signed-off-by: Xiaocheng Li <lix@codeaurora.org>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Now that alarmtimer_remove has been simplified, change
its name to _dequeue to better match its paired _enqueue
function.
Change-Id: I234362798c5eb8a1f357758e40cbc794b77e2061
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Colin Cross <ccross@android.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Smatch complains that if we pass an invalid clock type then "ts" is
never set. We need to check for errors earlier, otherwise we end up
passing uninitialized stack data to userspace.
Change-Id: Ia09058462fc9815f4cf8ff577884d02bc71f7721
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Per Colin's comment:
"The "support old userspace code" comment for those two ioctls has
been there since pre-Android 1.0. Those apis are not exposed to
Android apps, I don't see any problem deleting them."
Thus this patch removes the ANDROID_ALARM_SET_OLD and
ANDROID_ALARM_SET_AND_WAIT_OLD ioctl compatability
logic.
Change-Id: Ifb7d2e8dee0fe52d4cd6148f5014c4b607d8813e
Cc: Serban Constantinescu <serban.constantinescu@arm.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Colin Cross <ccross@google.com>
Cc: Android Kernel Team <kernel-team@android.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Little cleanups. Enum value ANDROID_ALARM_TYPE_COUNT was treated as
an alarm type within a switch statement. That condition was unreachable
though.
Change-Id: I6d66d0155dc44c0e7b01fe44adfc2f39f78176fc
Signed-off-by: Dae S. Kim <dae@velatum.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Fixes the following sparse warning:
drivers/staging/android/alarm-dev.c:259:35: warning: Using plain integer as NULL pointer
Change-Id: Ie4eca65f820ee67d695030a885eb45438d7b279e
Cc: Brian Swetland <swetland@google.com>
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Rename a macro to make it explicit it's for debugging.
Use %s: __func__ instead of embedding function names.
Coalesce formats, align arguments.
Change-Id: I583efa9ea4aeb4405dc0499b00995a049de52506
Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
This is a whole or partial revert of:
49740364548 misc: Import SM-G900F kernel source code
9c66e26930 rtc: alarm: set power_on_alarm again when calling alarm_resume
446d682932 alarm : Fix the race conditions in alarm-dev.c
eeb31ff78d rtc:alarm: remove alarm_shutdown hook in alarm driver
aaf95a368d rtc: alarm: update power_on alarm setting logic
aec339ee1f kernel: alarm: setup the RTC immediately for poweroff alarm
6a5881bcb1 rtc: alarm: Proper handling of spinlock
c83a382633 kernel: alarm: Do not call rtc_alarm_irq_enable in IRQ Disabled context
091c9afe14 kernel: alarm: add dedicated alarm type for poweroff alarm
1b2c1c64aa kernel: alarm: :fix the BUG that device automatically powers on
7289fdd2e0 rtc: alarm: Set power-on alarm 120 sec before actual alarm time
c1b2e47058 rtc: alarm: Add power-on alarm feature
f132c6cf77 Merge commit 'AU_LINUX_ANDROID_ICS.04.00.04.00.126' into msm-3.4
d074fa2796 Merge remote-tracking branch 'common/android-3.0' into msm-3.0
3f2bc4d6eb Initial Contribution
692e468137 rtc alarm: fix bad index when canceling alarms[]
2cd24680f6 rtc: alarm: Update hrtimer if alarm at the head of the queue is reprogrammed
b2a4ab2aa0 rtc: alarm: Don't use save_time_delta.
fa56540eb5 rtc: alarm: Add in-kernel alarm interface
b54b33d0b9 rtc: Add android alarm driver.
Change-Id: Iadf132deb9be432910badffb222177a253de81f5
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
This reverts commit 69e80b0b102c0eadf7a5ea8984e5f3dd9109fe43.
Change-Id: Ieddfd00f9e0448590a4e096ef933bc219d8efadc
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
This reverts commit e2f192e02955efcac46f0853eadaaa52ae642a93.
Change-Id: I7216659b94d8621265896930ad99f233ddcf1f75
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
* The comment says this case isn't supposed to be here for H-projects,
variables it depends on are ifndef-ed out for H-projects, just get rid
of it.
Change-Id: Ic67a1e97c4429dd5cf4df9e2f45fb63d13e4054f
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
added boundary check not to override allocated buffer.
Signed-off-by: Insun Song <insun.song@broadcom.com>
Change-Id: I76211db7ef595fc41cf5d5d58de79cedfe80e521
Bug: 32125310
CVE-2017-0567
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
1) The default_chan_list buffer overflow is avoided by checking
n_nodfs index does not exceed num_chans, which is the length
of default_chan_list buffer.
2) The SSID length check 32(max limit) is done and then the SSID
name copied in extra buffer is null terminated. The extra buffer
is allocated a length of of 33 in wl_iw_ioctl.c.
3) Issue of chances of cumulative results->pkt_count length
exceeding allocated memory length of results->total_count is
avoided in this fix. change_array is the destination array
whose length is allocated to results->total_count.
Signed-off-by: Sudhir Kohalli <sudhir.kohalli@broadcom.com>
Bug: 34197514
Bug: 34199963
Bug: 34198729
Change-Id: I0cd268ab696daac938a99f451607a3f4b2cfaed3
[haggertk]: Partial patch - dhd_handle_swc_evt() changes not relevant,
this bcmdhd version does not contain that function
CVE-2017-0568
CVE-2017-0569
CVE-2017-0570
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
prevent buffer overrun case where WLC_GET_VALID_CHANNELS IOCTL
overriden by attacker and its return manipulated.
Signed-off-by: Insun Song <insun.song@broadcom.com>
Change-Id: Ifbbaa3c2bdfd9bea7533d605303f18e17c8d85cc
Bug: 34197514
CVE-2017-0568
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
added boundary check not to override allocated buffer
Signed-off-by: Insun Song <insun.song@broadcom.com>
Change-Id: Iad44141ba4e4cd224eda292c05ffe525bf74227d
Bug: 34203305
CVE-2017-0571
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
added boundary check not to override allocated buffer.
Specially when user input corrupted or manipulated.
Signed-off-by: Insun Song <insun.song@broadcom.com>
Change-Id: Id6196da10111517696eda5f186b1e2dd19f66085
Bug: 34469904
CVE-2017-0573
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Make sure segno and blkoff read from raw image are valid.
Fixed conflicts due to missing commit 1e968fdfe69e
("f2fs: introduce f2fs_cp_error for readability") and commit 6bacf52fb58a
("f2fs: add unlikely() macro for compiler more aggressively").
(url https://sourceforge.net/p/linux-f2fs/mailman/message/35835945)
Signed-off-by: Jin Qian <jinqian@google.com>
Signed-off-by: Siqi Lin <siqilin@google.com>
Bug: 36588520
Change-Id: Iba66ab97d3d0870ea48b5ef192d9075f225a934a
CVE-2017-10663
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
commit b9dd46188edc2f0d1f37328637860bb65a771124 upstream.
F2FS uses 4 bytes to represent block address. As a result, supported
size of disk is 16 TB and it equals to 16 * 1024 * 1024 / 2 segments.
Signed-off-by: Jin Qian <jinqian@google.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 36815012
Change-Id: I30ea36df066bc07e32e767336b7cae12063fe415
CVE-2017-10662
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
f2fs currently only supports 4KB block size and 2MB segment size.
Sanity check log_blocks_per_seg == 9, i.e. 2MB/4KB = (1 << 9)
Partially
(cherry-picked from commit 9a59b62fd88196844cee5fff851bee2cfd7afb6e)
f2fs: do more integrity verification for superblock
Do more sanity check for superblock during ->mount.
Signed-off-by: Chao Yu <chao2.yu@samsung.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Bug: 36817013
Change-Id: I0be52e54fba82083068337ceb9f7ad985a87319f
Signed-off-by: Jin Qian <jinqian@google.com>
CVE-2017-0750
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Overflow of reference counter can lead to memory leak.
Before incrementing the reference count, check with
U32_MAX and return for error check.
Bug: 35467471
Change-Id: Ib96d36574ee086ec73c9836110cb2c98e8ae3d66
Acked-by: Mohammed Javid <mjavid@qti.qualcomm.com>
Signed-off-by: Utkarsh Saxena <usaxena@codeaurora.org>
CVE-2017-0746
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
This reports an error to the caller after adding the bound checks,
otherwise potentially undefined/unexpected behaviour may result.
Change-Id: Id2897aa5ce4587762b5eda89f7481788d689d0a8
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
syzkaller found a way to trigger double frees from ip_mc_drop_socket()
It turns out that leave a copy of parent mc_list at accept() time,
which is very bad.
Very similar to commit 8b485ce69876 ("tcp: do not inherit
fastopen_req from parent")
Initial report from Pray3r, completed by Andrey one.
Thanks a lot to them !
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Pray3r <pray3r.z@gmail.com>
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
CVE-2017-8890
Change-Id: I5880939b0ad2c19dcb013149dcbc7c479083dad6
Regulator enable and disable of CSIPHY depends on the CSID module.
Make the enable and disable of clk regulator independent of CSIPHY.
Bug: 33299365
CRs-Fixed: 1107702
Change-Id: Iabb5eb28d63b34a4c3201c53be17054a1907f4fe
Signed-off-by: Ravi Kishore Tanuku <rktanuku@codeaurora.org>
Signed-off-by: VijayaKumar T M <vtmuni@codeaurora.org>
Signed-off-by: Dennis Cagle <d-cagle@codeaurora.org>
(cherry picked from commit b1bb44c9cca61e48ec6158abad6e7969a8e58abf)
CVE-2017-8264
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
When allocating userspace memory keep reference to memory
allocation till it is completely initialized and info is send back
to userspace
Bug: 32938443
CRs-Fixed: 2029113
Change-Id: Id72c82bf98c094ecbd4722813c732a998dcbb188
Signed-off-by: Tarun Karra <tkarra@codeaurora.org>
Signed-off-by: Sunil Khatri <sunilkh@codeaurora.org>
Signed-off-by: Dennis Cagle <d-cagle@codeaurora.org>
CVE-2017-8262
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
In msm_ispif_is_intf_valid(),
we convert a enum variable msm_ispif_vfe_intf,
to uint8_t type for validating.
This could cause potential issue,
if the value is crafted in such a way that lower 8bits pass the validation.
Don't use uint8_t as input parm to avoid such vulnerability.
CRs-Fixed: 2008469
Change-Id: I4ee400ac0edd830decfbe5712966d968976a268a
Signed-off-by: Gaoxiang Chen <gaochen@codeaurora.org>
CVE-2017-8260
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Serialize core_info_read with lock so that multiple concurrent
threads do not cause the write to overflow. Also have the bound
check to avoid overflow in write_str function.
CRs-Fixed: 2013361
CAF-Change-Id: Ia18a4b94cafd69af1d367861f2499fc202f18e9f
Signed-off-by: Abdulla Anam <abdullahanam@codeaurora.org>
Signed-off-by: Sanjay Singh <sisanj@codeaurora.org>
CVE-2017-8244
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: I8d21d662534f1679594042f3a5b6bcfb4884e11f
The ipa_ioc_query_intf_rx_props structure comes
from the ioctl handler, and it is verified that
the size of rx buffer does not exceed the
IPA_NUM_PROPS_MAX elements. It is also verified
that the "entry->rx" buffer does not exceed
IPA_NUM_PROPS_MAX when "entry" is allocated.
However, the sizes of the buffer "rx->rx" and
the buffer "entry->rx" are not guaranteed to
be the same and will lead memory corruption
issue. The fix is to add the check before
memcpy.
CAF-Change-Id: Idf5c2d32f47c1a1cffeaa5607193855188893ddb
Signed-off-by: Skylar Chang <chiaweic@codeaurora.org>
[haggertk]: Backport to 3.4/msm8974
CVE-2017-8236
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: Ib0d0fb7b9564f9484f141df9866d121b2dd2b293
Under CONFIG_STRICT_DEVMEM, reading System RAM through /dev/mem is
disallowed. However, on x86, the first 1MB was always allowed for BIOS
and similar things, regardless of it actually being System RAM. It was
possible for heap to end up getting allocated in low 1MB RAM, and then
read by things like x86info or dd, which would trip hardened usercopy:
usercopy: kernel memory exposure attempt detected from ffff880000090000 (dma-kmalloc-256) (4096 bytes)
This changes the x86 exception for the low 1MB by reading back zeros for
System RAM areas instead of blindly allowing them. More work is needed to
extend this to mmap, but currently mmap doesn't go through usercopy, so
hardened usercopy won't Oops the kernel.
Change-Id: I6732f317b537c96046427bdcf805803dc138129a
Reported-by: Tommi Rantala <tommi.t.rantala@nokia.com>
Tested-by: Tommi Rantala <tommi.t.rantala@nokia.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
CVE-2017-7889
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
commit ef0579b64e93188710d48667cb5e014926af9f1b upstream.
The ahash API modifies the request's callback function in order
to clean up after itself in some corner cases (unaligned final
and missing finup).
When the request is complete ahash will restore the original
callback and everything is fine. However, when the request gets
an EBUSY on a full queue, an EINPROGRESS callback is made while
the request is still ongoing.
In this case the ahash API will incorrectly call its own callback.
This patch fixes the problem by creating a temporary request
object on the stack which is used to relay EINPROGRESS back to
the original completion function.
This patch also adds code to preserve the original flags value.
Fixes: ab6bf4e5e5e4 ("crypto: hash - Fix the pointer voodoo in...")
Reported-by: Sabrina Dubroca <sd@queasysnail.net>
Tested-by: Sabrina Dubroca <sd@queasysnail.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CVE-2017-7618
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: Id60b454614430baa609a1d597b051c594ec0a3af
The ahash_def_finup() can make use of the request save/restore functions,
thus make it so. This simplifies the code a little and unifies the code
paths.
Note that the same remark about free()ing the req->priv applies here, the
req->priv can only be free()'d after the original request was restored.
Finally, squash a bug in the invocation of completion in the ASYNC path.
In both ahash_def_finup_done{1,2}, the function areq->base.complete(X, err);
was called with X=areq->base.data . This is incorrect , as X=&areq->base
is the correct value. By analysis of the data structures, we see the areq is
of type 'struct ahash_request' , areq->base is of type 'struct crypto_async_request'
and areq->base.completion is of type crypto_completion_t, which is defined in
include/linux/crypto.h as:
typedef void (*crypto_completion_t)(struct crypto_async_request *req, int err);
This is one lead that the X should be &areq->base . Next up, we can inspect
other code which calls the completion callback to give us kind-of statistical
idea of how this callback is used. We can try:
$ git grep base\.complete\( drivers/crypto/
Finally, by inspecting ahash_request_set_callback() implementation defined
in include/crypto/hash.h , we observe that the .data entry of 'struct
crypto_async_request' is intended for arbitrary data, not for completion
argument.
Change-Id: I8e7841ed8a70b361c47091e2e121ca273d37b9d2
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: David S. Miller <davem@davemloft.net>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Filesystem encryption ostensibly supported revoking a keyring key that
had been used to "unlock" encrypted files, causing those files to become
"locked" again. This was, however, buggy for several reasons, the most
severe of which was that when key revocation happened to be detected for
an inode, its fscrypt_info was immediately freed, even while other
threads could be using it for encryption or decryption concurrently.
This could be exploited to crash the kernel or worse.
This patch fixes the use-after-free by removing the code which detects
the keyring key having been revoked, invalidated, or expired. Instead,
an encrypted inode that is "unlocked" now simply remains unlocked until
it is evicted from memory. Note that this is no worse than the case for
block device-level encryption, e.g. dm-crypt, and it still remains
possible for a privileged user to evict unused pages, inodes, and
dentries by running 'sync; echo 3 > /proc/sys/vm/drop_caches', or by
simply unmounting the filesystem. In fact, one of those actions was
already needed anyway for key revocation to work even somewhat sanely.
This change is not expected to break any applications.
In the future I'd like to implement a real API for fscrypt key
revocation that interacts sanely with ongoing filesystem operations ---
waiting for existing operations to complete and blocking new operations,
and invalidating and sanitizing key material and plaintext from the VFS
caches. But this is a hard problem, and for now this bug must be fixed.
This bug affected almost all versions of ext4, f2fs, and ubifs
encryption, and it was potentially reachable in any kernel configured
with encryption support (CONFIG_EXT4_ENCRYPTION=y,
CONFIG_EXT4_FS_ENCRYPTION=y, CONFIG_F2FS_FS_ENCRYPTION=y, or
CONFIG_UBIFS_FS_ENCRYPTION=y). Note that older kernels did not use the
shared fs/crypto/ code, but due to the potential security implications
of this bug, it may still be worthwhile to backport this fix to them.
Fixes: b7236e21d55f ("ext4 crypto: reorganize how we store keys in the inode")
Cc: stable@vger.kernel.org # v4.2+
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Acked-by: Michael Halcrow <mhalcrow@google.com>
[haggertk]: Backport to 3.4/msm8974
CVE-2017-7374
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: I2204233b893960f4e0e33c58f6135920724e84b1
Francescodario Cuzzocrea
Kevin F. Haggerty
Dave Daynard
leonardo meitz
John Stultz
Todd Poynor
Al Viro
Josh Cartwright
Xiaocheng Li
Dan Carpenter
Dae S. Kim
Devendra Naga
Sachin Kamat
Joe Perches
Insun Song
Sudhir Kohalli
myfluxi
Alex Elder
Jin Qian
Jin Qian
Utkarsh Saxena
Andrea Arcangeli
Craig Gallek
Eric Dumazet
Nick Desaulniers
Dennis Cagle
Gaoxiang Chen
Abdulla Anam
Skylar Chang
Kees Cook
Herbert Xu
Marek Vasut
Eric Biggers