GitLab

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 c97b5c0d, reversing
changes made to 6b5cc177

.

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 f0d1bec9d58d ("new helper:
copy_page_from_iter()") and 637b58c2887e ("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)

Validate input argument before writing into pmu_constraints_codes
array

Change-Id: Id68b1d2201ab1af783af2236833b1dc894e08cc7
Signed-off-by: Kishor PK <kpbhat@codeaurora.org>
Signed-off-by: Naveen Ramaraj <nramaraj@codeaurora.org>

Prevent unintended kernel NULL pointer dereferencing.

Orignal code:
  hlist_del_rcu(&event->hlist_entry);

Fix: Adding pointer check:
  if(!hlist_unhashed(&p_event->hlist_entry))
    hlist_del_rcu(&p_event->hlist_entry);

Bug: 25364034
Change-Id: Ieda6d8f4bb567827fa6c7709e9e729905c6c3882
Signed-off-by: Yuan Lin <yualin@google.com>

(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>

Signed-off-by: Patrick Tjin <pattjin@google.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

    git://codeaurora.org/external/wlan/prima.git



    41d7e5b wlan: release 3.2.3.23
    11cfab7 wlan: check for sus_res_mcastbcast_filter_valid before resetting

Change-Id: I828c6e73eb13ec42447f2069ad20b4576c2c4090
Signed-off-by: Thierry Strudel <tstrudel@google.com>

While testing the pid namespace code I hit this nasty warning.

[  176.262617] ------------[ cut here ]------------
[  176.263388] WARNING: at /home/eric/projects/linux/linux-userns-devel/kernel/softirq.c:160 local_bh_enable_ip+0x7a/0xa0()
[  176.265145] Hardware name: Bochs
[  176.265677] Modules linked in:
[  176.266341] Pid: 742, comm: bash Not tainted 3.7.0userns+ #18
[  176.266564] Call Trace:
[  176.266564]  [<ffffffff810a539f>] warn_slowpath_common+0x7f/0xc0
[  176.266564]  [<ffffffff810a53fa>] warn_slowpath_null+0x1a/0x20
[  176.266564]  [<ffffffff810ad9ea>] local_bh_enable_ip+0x7a/0xa0
[  176.266564]  [<ffffffff819308c9>] _raw_spin_unlock_bh+0x19/0x20
[  176.266564]  [<ffffffff8123dbda>] proc_free_inum+0x3a/0x50
[  176.266564]  [<ffffffff8111d0dc>] free_pid_ns+0x1c/0x80
[  176.266564]  [<ffffffff8111d195>] put_pid_ns+0x35/0x50
[  176.266564]  [<ffffffff810c608a>] put_pid+0x4a/0x60
[  176.266564]  [<ffffffff8146b177>] tty_ioctl+0x717/0xc10
[  176.266564]  [<ffffffff810aa4d5>] ? wait_consider_task+0x855/0xb90
[  176.266564]  [<ffffffff81086bf9>] ? default_spin_lock_flags+0x9/0x10
[  176.266564]  [<ffffffff810cab0a>] ? remove_wait_queue+0x5a/0x70
[  176.266564]  [<ffffffff811e37e8>] do_vfs_ioctl+0x98/0x550
[  176.266564]  [<ffffffff810b8a0f>] ? recalc_sigpending+0x1f/0x60
[  176.266564]  [<ffffffff810b9127>] ? __set_task_blocked+0x37/0x80
[  176.266564]  [<ffffffff810ab95b>] ? sys_wait4+0xab/0xf0
[  176.266564]  [<ffffffff811e3d31>] sys_ioctl+0x91/0xb0
[  176.266564]  [<ffffffff810a95f0>] ? task_stopped_code+0x50/0x50
[  176.266564]  [<ffffffff81939199>] system_call_fastpath+0x16/0x1b
[  176.266564] ---[ end trace 387af88219ad6143 ]---

It turns out that spin_unlock_bh(proc_inum_lock) is not safe when
put_pid is called with another spinlock held and irqs disabled.

For now take the easy path and use spin_lock_irqsave(proc_inum_lock)
in proc_free_inum and spin_loc_irq in proc_alloc_inum(proc_inum_lock).
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Bug: 22173056
Backport: commits 0f7aa3c0

 to this one are backport of mnt namespace
Signed-off-by: Thierry Strudel <tstrudel@google.com>
(cherry picked from commit dfb2ea45becb198beeb75350d0b7b7ad9076a38f)

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 98f842e675f96ffac96e6c50315790912b2812be)

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 bf056bfa80596a5d14b26b17276a56a0dcb080e5)

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 33d6dce607573b5fd7a43168e0d91221b3ca532b)

- 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 0c55cfc4166d9a0f38de779bd4d75a90afbe7734)

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 7a472ef4be8387bc05a42e16309b02c8ca943a40)

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 771b1371686e0a63e938ada28de020b9a0040f55)

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 8823c079ba7136dc1948d6f6dcb5f8022bde438e)

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
(cherry picked from commit 808d4e3cfdcc52b19276175464f6dbca4df13b09)

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 156cacb1d0d36b0d0582d9e798e58e0044f516b3)

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 c3b2da314834499f34cba94f7053e55f6d6f92d8)

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 f015f1267b23d3530d3f874243fb83cb5f443005)