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
System V IPCs are not compliant with Android's application lifecycle
because allocated resources are not freeable by the low memory killer.
This lead to global kernel resource leakage.
For example, there is no way to automatically release a SysV
semaphore allocated in the kernel when:
- a buggy or malicious process exits
- a non-buggy and non-malicious process crashes or is explicitly
killed.
Killing processes automatically to make room for new ones is an
important part of Android's application lifecycle implementation.
This means that, even assuming only non-buggy and non-malicious
code, it is very likely that over time, the kernel global tables
used to implement SysV IPCs will fill up.
Bug: 24551430
Bug: 22300191
Signed-off-by: Patrick Tjin <pattjin@google.com>
Change-Id: I98d592819974acbd5fb47d526ed1ce3700ae1bd5
These messages may cause watchdog timeout. For the usecases that
use the ab or ib greater than max, the max will be taken and if that
is not enough, underrun would happen, so this message would not be
necessary.
Signed-off-by: Huaibin Yang <huaibiny@codeaurora.org>
Signed-off-by: Naseer Ahmed <naseer@codeaurora.org>
Increase the wait timeout for context detachment to 30s instead
of 10s. Large IB's can take longer than 10s to retire and if a
hang happens then recovering from the hang and completing the
long IB's will take much longer than 10s, bump this timer to
30s which should be sufficient for the context's commands to
retire even if hang happens.
Change-Id: I610186473208c574b0bcada0b62a7407ae171d37
Signed-off-by: Harshdeep Dhatt <hdhatt@codeaurora.org>
Per RFC 6724, section 4, "Candidate Source Addresses":
It is RECOMMENDED that the candidate source addresses be the set
of unicast addresses assigned to the interface that will be used
to send to the destination (the "outgoing" interface).
Add a sysctl to enable this behaviour.
Signed-off-by: Erik Kline <ek@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[Simplified back-port of net-next 3985e8a3611a93bb36789f65db862e5700aab65e]
Bug: 19470192
Bug: 21832279
Bug: 22464419
Change-Id: Icd96382f814a6f3ea53f05beb98c266b1929c5a3
Assign a unique proc inode to each namespace, and use that
inode number to ensure we only allocate at most one proc
inode for every namespace in proc.
A single proc inode per namespace allows userspace to test
to see if two processes are in the same namespace.
This has been a long requested feature and only blocked because
a naive implementation would put the id in a global space and
would ultimately require having a namespace for the names of
namespaces, making migration and certain virtualization tricks
impossible.
We still don't have per superblock inode numbers for proc, which
appears necessary for application unaware checkpoint/restart and
migrations (if the application is using namespace file descriptors)
but that is now allowd by the design if it becomes important.
I have preallocated the ipc and uts initial proc inode numbers so
their structures can be statically initialized.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
(cherry picked from commit 98f842e675)
Change the proc namespace files into symlinks so that
we won't cache the dentries for the namespace files
which can bypass the ptrace_may_access checks.
To support the symlinks create an additional namespace
inode with it's own set of operations distinct from the
proc pid inode and dentry methods as those no longer
make sense.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
(cherry picked from commit bf056bfa80)
Generalize the proc inode allocation so that it can be
used without having to having to create a proc_dir_entry.
This will allow namespace file descriptors to remain light
weight entitities but still have the same inode number
when the backing namespace is the same.
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
(cherry picked from commit 33d6dce607)
- Add a filesystem flag to mark filesystems that are safe to mount as
an unprivileged user.
- Add a filesystem flag to mark filesystems that don't need MNT_NODEV
when mounted by an unprivileged user.
- Relax the permission checks to allow unprivileged users that have
CAP_SYS_ADMIN permissions in the user namespace referred to by the
current mount namespace to be allowed to mount, unmount, and move
filesystems.
Acked-by: "Serge E. Hallyn" <serge@hallyn.com>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
(cherry picked from commit 0c55cfc416)
Sharing mount subtress with mount namespaces created by unprivileged
users allows unprivileged mounts created by unprivileged users to
propagate to mount namespaces controlled by privileged users.
Prevent nasty consequences by changing shared subtrees to slave
subtress when an unprivileged users creates a new mount namespace.
Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
(cherry picked from commit 7a472ef4be)
This will allow for support for unprivileged mounts in a new user namespace.
Acked-by: "Serge E. Hallyn" <serge@hallyn.com>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
(cherry picked from commit 771b137168)
setns support for the mount namespace is a little tricky as an
arbitrary decision must be made about what to set fs->root and
fs->pwd to, as there is no expectation of a relationship between
the two mount namespaces. Therefore I arbitrarily find the root
mount point, and follow every mount on top of it to find the top
of the mount stack. Then I set fs->root and fs->pwd to that
location. The topmost root of the mount stack seems like a
reasonable place to be.
Bind mount support for the mount namespace inodes has the
possibility of creating circular dependencies between mount
namespaces. Circular dependencies can result in loops that
prevent mount namespaces from every being freed. I avoid
creating those circular dependencies by adding a sequence number
to the mount namespace and require all bind mounts be of a
younger mount namespace into an older mount namespace.
Add a helper function proc_ns_inode so it is possible to
detect when we are attempting to bind mound a namespace inode.
Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
(cherry picked from commit 8823c079ba)
normally we deal with lock_mount()/umount races by checking that
mountpoint to be is still in our namespace after lock_mount() has
been done. However, do_add_mount() skips that check when called
with MNT_SHRINKABLE in flags (i.e. from finish_automount()). The
reason is that ->mnt_ns may be a temporary namespace created exactly
to contain automounts a-la NFS4 referral handling. It's not the
namespace of the caller, though, so check_mnt() would fail here.
We still need to check that ->mnt_ns is non-NULL in that case,
though.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
(cherry picked from commit 156cacb1d0)
Btrfs has to make sure we have space to allocate new blocks in order to modify
the inode, so updating time can fail. We've gotten around this by having our
own file_update_time but this is kind of a pain, and Christoph has indicated he
would like to make xfs do something different with atime updates. So introduce
->update_time, where we will deal with i_version an a/m/c time updates and
indicate which changes need to be made. The normal version just does what it
has always done, updates the time and marks the inode dirty, and then
filesystems can choose to do something different.
I've gone through all of the users of file_update_time and made them check for
errors with the exception of the fault code since it's complicated and I wasn't
quite sure what to do there, also Jan is going to be pushing the file time
updates into page_mkwrite for those who have it so that should satisfy btrfs and
make it not a big deal to check the file_update_time() return code in the
generic fault path. Thanks,
Signed-off-by: Josef Bacik <josef@redhat.com>
(cherry picked from commit c3b2da3148)
Add comments describing what the directions "up" and "down" mean and ref count
handling to the VFS mount following family of functions.
Signed-off-by: Valerie Aurora <vaurora@redhat.com> (Original author)
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
(cherry picked from commit f015f1267b)
copy_tree() can theoretically fail in a case other than ENOMEM, but always
returns NULL which is interpreted by callers as -ENOMEM. Change it to return
an explicit error.
Also change clone_mnt() for consistency and because union mounts will add new
error cases.
Thanks to Andreas Gruenbacher <agruen@suse.de> for a bug fix.
[AV: folded braino fix by Dan Carpenter]
Original-author: Valerie Aurora <vaurora@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Valerie Aurora <valerie.aurora@gmail.com>
Cc: Andreas Gruenbacher <agruen@suse.de>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
(cherry picked from commit be34d1a3bc)
don't rely on proc_mounts->m being the first field; container_of()
is there for purpose. No need to bother with ->private, while
we are at it - the same container_of will do nicely.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
(cherry picked from commit 6ce6e24e72)
it's enough to set ->mnt_ns of internal vfsmounts to something
distinct from all struct mnt_namespace out there; then we can
just use the check for ->mnt_ns != NULL in the fast path of
mntput_no_expire()
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
(cherry picked from commit f7a99c5b7c)