step_boundary can take values upto the total_steps
Validate the step_boundary before consuming it.
Convert the type of step_index and region_index to uint16_t
step_index and region_index cannot be negative.
Bug: 27890772
CRs-Fixed: 1001092
Change-Id: I1f23fd6f28bb897824a1ef99a8873b9f986eee70
Signed-off-by: Rajesh Bondugula <rajeshb@codeaurora.org>
In the MMC card debug_fs the read and write handlers use the strlcat
and sscanf, without checking the pointer given.
Since the pointer is not checked it is possible to write
everywhere (ring 0 or 3).
In order to fix it, an access_ok function is being used to verify
the buffer's pointer supplied by user is valid.
Bug: 28769136
CRs-fixed: 545716
Change-Id: Ia710b6af5a95974fc930ca902e8ff18afa4e17ba
Signed-off-by: Raviv Shvili <rshvili@codeaurora.org>
The tty atomic_write_lock does not provide an exclusion guarantee for
the tty driver if the termios settings are LECHO & !OPOST. And since
it is unexpected and not allowed to call TTY buffer helpers like
tty_insert_flip_string concurrently, this may lead to crashes when
concurrect writers call pty_write. In that case the following two
writers:
* the ECHOing from a workqueue and
* pty_write from the process
race and can overflow the corresponding TTY buffer like follows.
If we look into tty_insert_flip_string_fixed_flag, there is:
int space = __tty_buffer_request_room(port, goal, flags);
struct tty_buffer *tb = port->buf.tail;
...
memcpy(char_buf_ptr(tb, tb->used), chars, space);
...
tb->used += space;
so the race of the two can result in something like this:
A B
__tty_buffer_request_room
__tty_buffer_request_room
memcpy(buf(tb->used), ...)
tb->used += space;
memcpy(buf(tb->used), ...) ->BOOM
B's memcpy is past the tty_buffer due to the previous A's tb->used
increment.
Since the N_TTY line discipline input processing can output
concurrently with a tty write, obtain the N_TTY ldisc output_lock to
serialize echo output with normal tty writes. This ensures the tty
buffer helper tty_insert_flip_string is not called concurrently and
everything is fine.
Note that this is nicely reproducible by an ordinary user using
forkpty and some setup around that (raw termios + ECHO). And it is
present in kernels at least after commit
d945cb9cce (pty: Rework the pty layer to
use the normal buffering logic) in 2.6.31-rc3.
js: add more info to the commit log
js: switch to bool
js: lock unconditionally
js: lock only the tty->ops->write call
Bug: 28803396
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: I9e235db6ec2bb950f26bd8a23f6145dab5dc0a15
Git-commit: 4291086b1f
Git-repo:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Avijit Kanti Das <avijitnsec@codeaurora.org>
[rsiddoji@codeaurora.org: resolve trivial merge conflicts]
Signed-off-by: Ravi Kumar S <rsiddoji@codeaurora.org>
Makesure the number of buffers count is less than
the maximum limit to avoid structure overflow errors.
Bug: 28598515
Change-Id: Ia19481c42610ecf1f395bb94138495a848b1eb28
Validate the number of buffers count variable before
using it to avoid structure overflow error.
Bug: 28598501
Change-Id: I61582c93e0f26ec6842e437134fb8a42bdbc36ff
CRs-fixed: 563654
Signed-off-by: Pachika, Vikas Reddy <vpachi@codeaurora.org>
Check if there is no integer overflow before using req_len and
resp_len (received from user space). If an overflow is detected
then exit the operation.
Bug: 28571496
Change-Id: I0459a6992bb3b280db42be63a275c55fa6105b1c
Signed-off-by: Hariprasad Dhalinarasimha <hnamgund@codeaurora.org>
fix to prevent kernel heap buffer overflow allows user
controlled data to be written to the heap via the
msm_camera actuator IOCTLs
Bug: 28557260
Change-Id: I4458831e28e0081fb2f5ae55506be866100e1b4f
Signed-off-by: Vasko Kalanoski <vaskok@codeaurora.org>
An enum value cci_i2c_master is not checked to be greater than 0.
Add the check.
Bug: 28441831
Change-Id: Ibe75ab7155def45d81b8127c5eda3fa2ed570bce
Signed-off-by: Xu Han <hanxu@codeaurora.org>
Remove some unused ioctl exposed, Also add
some bound checks for ioctl user params.
Bug: 28441831
Change-Id: Ifdd441fdb25fd20b005c4e4e1ebe4e203f1216ac
CRs-Fixed: 511382
Signed-off-by: Hariram Purushothaman <hpurus@codeaurora.org>
Signed-off-by: Shuzhen Wang <shuzhenw@codeaurora.org>
Bound check and validate userspace parameters direction,
number of steps and direction sign. Also fix possible
memory leak in certain error cases.
Bug: 28431531
CRs-Fixed: 511349
Change-Id: Icaa324468574494fb40f2de78e522090806744cb
Signed-off-by: Hariram Purushothaman <hpurus@codeaurora.org>
As per ANSI C Standard document, integer overflow is an undefined
behavior. So update the code to detect integer overflow before it happens.
Bug: 28430703
CRs-Fixed: 491629
Change-Id: Ifd90c05266477c7734710bb94b9021f8bb9ab761
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@codeaurora.org>
__copy_from_user does not do address check, so use
copy_from_user instead.
Bug: 28469042
Change-Id: I575c0f3c44b55a521c0d42828988c518c0640a29
CRs-Fixed: 545747
Signed-off-by: Hariprasad Dhalinarasimha <hnamgund@codeaurora.org>
In _kgsl_sharedmem_page_alloc():
- Make len of type size_t to be in line with size.
- Check for boundary limits of requested alloc size before honoring.
- Make sure sglen is greater than zero before marking it as end
of sg list.
Bug: 27475454
Change-Id: I5389bcef3478f2ccf2be5f719049867496235f28
Signed-off-by: Yuan Lin <yualin@google.com>
Use copy_to_user and copy_from_user for
copying data to/from user space
Change-Id: I98fb6352b654af8f78160738e7ccd902c3c70031
CRs-Fixed: 561028
CRs-Fixed: 605932
Bug: 27662174
Bug: 27777162
ALL WAPI ioctls WLAN_PRIV_SET_WAPI_MODE, WLAN_PRIV_GET_WAPI_MODE
WLAN_PRIV_SET_WAPI_ASSOC_INFO, WLAN_PRIV_SET_WAPI_KEY,
WLAN_PRIV_SET_WAPI_BKID, WLAN_PRIV_GET_WAPI_BKID are not being
used, hence removing the source code related to all these ioctls
Change-Id: I204cd579b4e29df7e995f30cc0aa8612bc7965ee
CRs-Fixed: 677410
Bug: 27776888
so we cannot utilize kernel facility "extra".
We need to copy the user data in kernel buffer
using copy_from_user function.
Change-Id: I550bf90fbbacb9d5ac4187ed423fca90fafccad1
CRs-Fixed: 596898
Bug: 27777501
Userspace supplies the actual number of used VFEs in session to ISPIF.
Validate the userspace input value and if found to be invalid, return
error.
BUG=27600832
Change-Id: I91944434e9a83d34af765c40bf8ad297a09ce2f5
prima to qcacld-2.0 propagation
Return failure to applications if ioctl is invoked with arguments
of improper length.
Bug: 27104184
Change-Id: I4459c5f39ca9c7a852772913578bd2122cb73879
Presently we are not validating the length of the essid received
and directly copying the buffer without size checking.
Perform bound checking before processing the scan req.
Change-Id: I786e4feb67bf039df3d217138a412da54f51787d
CRs-fixed: 890228
Bug: 27773913
Change the config from DEBUG_FS to MDP_DEBUG_FS to dump and
write the MDP, MDDI and HDMI debug registers. By default
CONFIG_MDP_DEBUG_FS should be disabled and can be enabled
through defconfig file.
Change-Id: I2ed8dcc30b19a80912734ec13f24a67351c38315
Signed-off-by: Raghavendra Ambadas <rambad@codeaurora.org>
Signed-off-by: Naseer Ahmed <naseer@codeaurora.org>
BUG=26404525
Validate the input arguments of MDP, MDDI and HDMI offset
values in the respective write functions.
Change-Id: Ida1b7ec292c365701fe17446019f625fdaff38d2
Signed-off-by: Raghavendra Ambadas <rambad@codeaurora.org>
Signed-off-by: Naseer Ahmed <naseer@codeaurora.org>
BUG=26404525
Previous upstream *stable* fix 14f81062 was incomplete.
A local process can trigger a system crash with an OOB read on buf.
This occurs when the state of buf gets out of sync. After an error in
pipe_iov_copy_to_user() read_pipe may exit having updated buf->offset
but not buf->len. Upon retrying pipe_read() while in
pipe_iov_copy_to_user() *remaining will be larger than the space left
after buf->offset e.g. *remaing = PAGE_SIZE, buf->len = PAGE_SIZE,
buf->offset = 0x300.
This is fixed by not updating the state of buf->offset until after the
full copy is completed, similar to how pipe_write() is implemented.
For stable kernels < 3.16.
Bug: 27721803
Change-Id: Iefffbcc6cfd159dba69c31bcd98c6d5c1f21ff2e
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
prima to qcacld-2.0 propagation
Check for valid length before copying the packet filter data from
userspace buffer to kernel space buffer to avoid buffer overflow
issue.
Bug: 26754117
Change-Id: I8d25a9d1b6909b6dda7a1d2aa80407ef2da821aa
Signed-off-by: Yuan Lin <yualin@google.com>
prima to qcacld-2.0 propagation
Return failure to applications if genie ioctl is invoked to configure
WPS/WPA/RSN IEs with arguments of improper length.
Bug: 27104184
Change-Id: I31e288db41e14b24be0e430afed3a5e360da1370
Signed-off-by: Yuan Lin <yualin@google.com>
for CLEAR_MCBC_FILTER IOCTL
Kernel assumes all SET IOCTL commands are assigned with even
numbers. But in our WLAN driver, some SET IOCTLS are assigned with
odd numbers. This leads kernel fail to check, for some SET IOCTLs,
whether user has the right permission to do SET operation.
Hence, in driver, before processing CLEAR_MCBC_FILTER IOCTL, making
sure user task has right permission to process the command.
Bug: 27104184
Change-Id: I2332845fa6793dc63b6f397a9ebf53d37a52a7c7
Signed-off-by: Yuan Lin <yualin@google.com>
for SET_POWER_PARAMS IOCTL
Kernel assumes all SET IOCTL commands are assigned with even
numbers. But in our WLAN driver, some SET IOCTLS are assigned with
odd numbers. This leads kernel fail to check, for some SET IOCTLs,
whether user has the right permission to do SET operation.
Hence, in driver, before processing SET_POWER_PARAMS IOCTL, making
sure user task has right permission to process the command.
Bug: 27104184
Change-Id: Iaab3d55c2acc75f65d6daf5998713cc9ff92a32c
Signed-off-by: Yuan Lin <yualin@google.com>
for SET_BAND_CONFIG IOCTL
Kernel assumes all SET IOCTL commands are assigned with even
numbers. But in our WLAN driver, some SET IOCTLS are assigned with
odd numbers. This leads kernel fail to check, for some SET IOCTLs,
whether user has the right permission to do SET operation.
Hence, in driver, before processing SET_BAND_CONFIG IOCTL, making
sure user task has right permission to process the command.
Bug: 27104184
Change-Id: I34e9d91f778b09eb73881aed5c6e3a10cbbd208c
Signed-off-by: Yuan Lin <yualin@google.com>
for SET_THREE_INT_GET_NONE
Kernel assumes all SET IOCTL commands are assigned with even
numbers. But in our WLAN driver, some SET IOCTLS are assigned with
odd numbers. This leads kernel fail to check, for some SET IOCTLs,
whether user has the right permission to do SET operation.
Hence, in driver, before processing SET_THREE_INT_GET_NONE IOCTL,
making sure user task has right permission to process the command.
Bug: 27104184
Change-Id: I8661872786adfb5492da505ba3960e62064ddd7e
Signed-off-by: Yuan Lin <yualin@google.com>
for QCSAP_IOCTL_DISASSOC_STA
Kernel assumes all SET IOCTL commands are assigned with even
numbers. But in our WLAN driver, some SET IOCTLS are assigned with
odd numbers. This leads kernel fail to check, for some SET IOCTLs,
whether user has the right permission to do SET operation.
Hence, in driver, before processing QCSAP_IOCTL_DISASSOC_STA IOCTL,
making sure user task has right permission to process the command.
Bug: 27104184
Change-Id: I7928789c0ce94a2b81495064496766b9e62d6ed8
Signed-off-by: Yuan Lin <yualin@google.com>
for QCSAP_IOCTL_SETWPSIE
Kernel assumes all SET IOCTL commands are assigned with even
numbers. But in our WLAN driver, some SET IOCTLS are assigned with
odd numbers. This leads kernel fail to check, for some SET IOCTLs,
whether user has the right permission to do SET operation.
Hence, in driver, before processing QCSAP_IOCTL_SETWPSIE IOCTL,
making sure user task has right permission to process the command.
Bug: 27104184
Change-Id: I66acff95d6151b32f1cb3c36a164e1de021e1e30
Signed-off-by: Yuan Lin <yualin@google.com>
for SET_VAR_INTS_GETNONE IOCTL
Kernel assumes all SET IOCTL commands are assigned with even
numbers. But in our WLAN driver, some SET IOCTLS are assigned with
odd numbers. This leads kernel fail to check, for some SET IOCTLs,
whether user has the right permission to do SET operation.
Hence, in driver, before processing SET_VAR_INTS_GETNONE, making
sure user task has right permission to process the command.
Bug: 27104184
Change-Id: Ia2465433aab6366160a167a62ca03e0ba720bcdb
Signed-off-by: Yuan Lin <yualin@google.com>
for SET_PACKET_FILTER IOCTL
Kernel assumes all SET IOCTL commands are assigned with even
numbers. But in our WLAN driver, some SET IOCTLS are assigned with
odd numbers. This leads kernel fail to check, for some SET IOCTLs,
whether user has the right permission to do SET operation.
Hence, in driver, before processing SET_PACKET_FILTER IOCTL, making
sure user task has right permission to process the command.
Bug: 27104184
Change-Id: I1edc65ee26c5e3e4260e0f6546434b0137493396
Signed-off-by: Yuan Lin <yualin@google.com>
for SET_CHAR_GET_NONE IOCTL
Kernel assumes all SET IOCTL commands are assigned with even
numbers. But in our WLAN driver, some SET IOCTLS are assigned with
odd numbers. This leads kernel fail to check, for some SET IOCTLs,
whether user has the right permission to do SET operation.
Hence, in driver, before processing SET_CHAR_GET_NONE IOCTLs, making
sure user task has right permission to process the command.
Bug: 27104184
Change-Id: Iccf25a9d1f1a7c13d3aaf2fc4bd3aebba740dbb2
Signed-off-by: Yuan Lin <yualin@google.com>
for SET_OEM_DATA_REQ IOCTL
Kernel assumes all SET IOCTL commands are assigned with even
numbers. But in our WLAN driver, some SET IOCTLS are assigned with
odd numbers. This leads kernel fail to check, for some SET IOCTLs,
whether user has the right permission to do SET operation.
Hence, in driver, before processing SET_OEM_DATA_REQ IOCTLs, making
sure user task has right permission to process the command.
Bug: 27104184
Change-Id: I651656fe11d4235232b76c972b5460b57e608449
Signed-off-by: Yuan Lin <yualin@google.com>
This reverts commit c97b5c0d3c, reversing
changes made to 6b5cc17714.
Change-Id: I2fbf3d21c74ff886640f6ba54d783a8c3d0a75b3
Signed-off-by: Patrick Tjin <pattjin@google.com>
pipe_iov_copy_{from,to}_user() may be tried twice with the same iovec,
the first time atomically and the second time not. The second attempt
needs to continue from the iovec position, pipe buffer offset and
remaining length where the first attempt failed, but currently the
pipe buffer offset and remaining length are reset. This will corrupt
the piped data (possibly also leading to an information leak between
processes) and may also corrupt kernel memory.
This was fixed upstream by commits f0d1bec9d5 ("new helper:
copy_page_from_iter()") and 637b58c288 ("switch pipe_read() to
copy_page_to_iter()"), but those aren't suitable for stable. This fix
for older kernel versions was made by Seth Jennings for RHEL and I
have extracted it from their update.
CVE-2015-1805
Bug: 27275324
Change-Id: I459adb9076fcd50ff1f1c557089c4e421b036ec4
References: https://bugzilla.redhat.com/show_bug.cgi?id=1202855
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 85c34d007116f8a8aafb173966a605fb03532f45)
(cherry pick from commit ab676b7d6fbf4b294bf198fb27ade5b0e865c7ce)
As pointed by recent post[1] on exploiting DRAM physical imperfection,
/proc/PID/pagemap exposes sensitive information which can be used to do
attacks.
This disallows anybody without CAP_SYS_ADMIN to read the pagemap.
[1] http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
[ Eventually we might want to do anything more finegrained, but for now
this is the simple model. - Linus ]
Change-Id: I26bcfef2a0d4d3d02da4c522b29615d8ec694600
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Acked-by: Andy Lutomirski <luto@amacapital.net>
Cc: Pavel Emelyanov <xemul@parallels.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Mark Seaborn <mseaborn@chromium.org>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Bug: 26038496
Poison pointer values should be small enough to find a room in
non-mmap'able/hardly-mmap'able space. E.g. on x86 "poison pointer space"
is located starting from 0x0. Given unprivileged users cannot mmap
anything below mmap_min_addr, it should be safe to use poison pointers
lower than mmap_min_addr.
The current poison pointer values of LIST_POISON{1,2} might be too big for
mmap_min_addr values equal or less than 1 MB (common case, e.g. Ubuntu
uses only 0x10000). There is little point to use such a big value given
the "poison pointer space" below 1 MB is not yet exhausted. Changing it
to a smaller value solves the problem for small mmap_min_addr setups.
The values are suggested by Solar Designer:
http://www.openwall.com/lists/oss-security/2015/05/02/6
Bug: 26186802
Change-Id: Ie2121a417b6a43ee6d119c996b5ec2ad6d01a0a7
Signed-off-by: Yuan Lin <yualin@google.com>
prctl_set_vma_anon_name could attempt to set the name across
two vmas at the same time due to a typo, which might corrupt
the vma list. Fix it to use tmp instead of end to limit
the name setting to a single vma at a time.
Change-Id: Ie32d8ddb0fd547efbeedd6528acdab5ca5b308b4
Reported-by: Jed Davis <jld@mozilla.com>
Signed-off-by: Colin Cross <ccross@android.com>
Limit the size of copy to the minimum of what was asked
for or the number of results returned to prevent leaking of
uninitialized kernel memory to userspace.
Bug: 24157888
Signed-off-by: Patrick Tjin <pattjin@google.com>
Change-Id: I7433135ea3345905c053a81d0d759619b46c1430
