CVE-2013-2094, CVE-2012-4220, CVE-2012-4221, CVE-2012-4222, CVE-2013-2596, CVE-2013-2595

https://www.codeaurora.org/projects/security-advisories

perf: Treat attr.config as u64 in perf_swevent_init()

Trinity discovered that we fail to check all 64 bits of
attr.config passed by user space, resulting to out-of-bounds
access of the perf_swevent_enabled array in
sw_perf_event_destroy().

Introduced in commit b0a873ebb ("perf: Register PMU
implementations").

Signed-off-by: Tommi Rantala <tt.rantala@gmail.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: davej@redhat.com
Cc: Paul Mackerras <paulus@samba.org>
Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Link: http://lkml.kernel.org/r/1365882554-30259-1-git-send-email-tt.rantala@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>

msm: msm_fb: remove mmio access through mmap

Disable access to mm io and add
appropriate range checks to ensure valid accesses
through framebuffer mmap. This prevents illegal
access into memory.

CRs-Fixed: 474706
Change-Id: If25166f2732433ef967e99c716440030b567aae9
Signed-off-by: Manoj Rao <manojraj@codeaurora.org>
(cherry picked from commit b571bef36cf51f9bb4cd1ad3ba23e3cee6d1d3cb)

Conflicts:

	drivers/video/msm/msm_fb.c

Signed-off-by: Raviteja <adimur@codeaurora.org>

msm: camera: Remove unused code used to map userspace buffers.

Remove MSM_CAM_IOCTL_SET_MEM_MAP_INFO IOCTL support, since the
usage of this IOCTL is now depreciated.

Change-Id: I8d0c99874ae9bd87aaaa10e039f2511a6dd20775
Signed-off-by: Kiran Kumar H N <hurlisal@codeaurora.org>

msm: kgsl: Detect and avoid malformed ioctl codes

Because we were using _IO_NR, one could construct a malformed ioctl
code that would avoid allocating memory yet go to a function that
expected that memory. Still use _IO_NR to index the array of ioctls,
but check that the full values match before jumping to the helper
function.

CRs-fixed: 385592
Change-Id: Ic0dedbaded469035bd0a2bb0f20fecb2a3045ca5
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Add permission checking for binder IPC.

Do not apply permission checks to private files.

Fix security_binder_transfer_binder hook.

Drop the owning task argument to security_binder_transfer_binder
since ref->node->proc can be NULL (dead owner?).
Revise the SELinux checking to apply a single transfer check between
the source and destination tasks.  Owning task is no longer relevant.
Drop the receive permission definition as it is no longer used.

This makes the transfer permission similar to the call permission; it is only
useful if you want to allow a binder IPC between two tasks (call permission)
but deny passing of binder references between them (transfer permission).

Change-Id: I51e7a9a6662e826073b35e4f70a57f9ec73e472e
Signed-off-by: William Roberts <w.roberts@sta.samsung.com>

Conflicts:

	drivers/staging/android/binder.c
Do not ratelimit audit messages. We want to see them all.

Change-Id: I19c29788cc33b0f59e0bdfe04fe67c247239c559
Enable setting security contexts on rootfs inodes.

rootfs (ramfs) can support setting of security contexts
by userspace due to the vfs fallback behavior of calling
the security module to set the in-core inode state
for security.* attributes when the filesystem does not
provide an xattr handler.  No xattr handler required
as the inodes are pinned in memory and have no backing
store.

This is useful in allowing early userspace to label individual
files within a rootfs while still providing a policy-defined
default via genfs.

Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
yaffs: fix getxattr support

When passed a buffer size of 0, getxattr(2) is documented to return the
size of the attribute value.  However, yaffs returns -ERANGE instead.
This breaks SELinux usage of getxattr.  Fix yaffs to return the
attribute size in this case.

Signed-off-by:  Stephen Smalley <sds@tycho.nsa.gov>
yaffs: set security attribute at file creation

Add support to yaffs to set the security attribute of new inodes when
they are created.  This parallels similar support in other filesystems,
and is a requirement for SELinux and other MAC systems.

Change-Id: I4038621dc92af43573ec022a7cf09a0ec1bd5870
Signed-off-by:  Stephen Smalley <sds@tycho.nsa.gov>
usb:gadget:android: avoid sending extra uevents

Don't schedule a uevet from android_disconnect
if there is no change in the connection state
and if the DISCONNECT event was already sent.
This patch will avoid these unecessary messages:

android_work: did not send uevent (0 0   (null))

Change-Id: I54d66ef84fc19791da94d32f82bf6e5dcef3786d
Upgrade ashmem to kk_3.5_rb1.21 from drivers/staging/android (4 commits)

drivers: staging: android: Fix ashmem vm range comparison to stop roll-over

Every time ASHMEM_CACHE_INV_RANGE was sent to an IOCTL a roll-over was
occurring, causing the check to fail. This was comparing a start + size
range with a start + end range, and if the start + end was less than the
start + size the ioctl would fail. The end value was always equal to
start + size from all tests I ran, and since the roll-over occurred with
start + end, it was always less than start. Setting the check to compare
start + size > end fixes this.

Change-Id: I3e4356ab40d8c745fd91eb0cc6b1aaed73494140
Signed-off-by: Matthew Trusten <mtrusten@codeaurora.org>

staging: android: ashmem: get_name,set_name not to hold ashmem_mutex

Problem:
There exists a path in ashmem driver that could lead to acquistion
of mm->mmap_sem, ashmem_mutex in reverse order. This could lead
to deadlock in the system.
For Example, assume that mmap is called on a ashmem region
in the context of a thread say T1.
 sys_mmap_pgoff (1. acquires mm->mmap_sem)
  |
   --> mmap_region
 	|
         ----> ashmem_mmap (2. acquires asmem_mutex)
 Now if there is a context switch after 1 and before 2,
 and if another thread T2 (that shares the mm struct) invokes an
 ioctl say ASHMEM_GET_NAME, this can lead to the following path

ashmem_ioctl
  |
  -->get_name (3. acquires ashmem_mutex)
	|
	---> copy_to_user (4. acquires the mm->mmap_sem)
Note that the copy_to_user could lead to a valid fault if no
physical page is allocated yet for the user address passed.
Now T1 has mmap_sem and is waiting for ashmem_mutex.
and T2 has the ashmem_mutex and is waiting for mmap_sem
Thus leading to deadlock.

Solution:
Do not call copy_to_user or copy_from_user while holding the
ahsmem_mutex. Instead copy this to a local buffer that lives
in the stack while holding this lock. This will maintain data
integrity as well never reverse the lock order.

Testing:
Created a unit test case to reproduce the problem.
Used the same to test this fix on kernel version 3.4.0
Ported the same patch to 3.8

Change-Id: Ib66f6265da91691acfd3be9ea8f5c9332c978751
CRs-Fixed: 600362
Signed-off-by: Shankar Brahadeeswaran <shankoo77@gmail.com>
Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Git-commit: e5834d620d61d01444c41958f1816d688a96433c
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>

ashmem: avoid deadlock between read and mmap calls

Avoid holding ashmem_mutex across code that can page fault.  Page faults
grab the mmap_sem for the process, which are also held by mmap calls
prior to calling ashmem_mmap, which locks ashmem_mutex.  The reversed
order of locking between the two can deadlock.

The calls that can page fault are read() and the ASHMEM_SET_NAME and
ASHMEM_GET_NAME ioctls.  Move the code that accesses userspace pages
outside the ashmem_mutex.

Bug: 9261835
Change-Id: If1322e981d29c889a56cdc9dfcbc6df2729a45e9
CRs-Fixed: 600362
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Git-repo: https://android.googlesource.com/kernel/common/
Git-commit: 0a9dea28170c90a7265250b66cc0df1253b0c501
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>

staging: ashmem: Fix the build failure when OUTER_CACHE is enabled

ashmem driver is failing to build when OUTER_CACHE is enabled
through the CACHE_L2X0 option. Fix it with appropriate new
offset routines.

Change-Id: I298f9bb32899f20e17407b5210d0859d6308c035
Signed-off-by: Trilok Soni <tsoni@codeaurora.org>
gpu/kgsl: update to ics_chocolate

AU_LINUX_ANDROID_ICS_CHOCOLATE.04.00.04.005.325

Change-Id: I4adf8f2d732526735d656bcf0f886fc69e1ba681
msm/display: ics_chocolate_rb4.2 -> ics_chocolate

Change-Id: If0611e38fd8df931b2a67a6c8f23ed19b299e03f
netfilter: qtaguid: initialize a local var to keep compiler happy.

There was a case that might have seemed like new_tag_stat was not
initialized and actually used.
Added comment explaining why it was impossible, and a BUG()
in case the logic gets changed.

Change-Id: I1eddd1b6f754c08a3bf89f7e9427e5dce1dfb081
Signed-off-by: JP Abgrall <jpa@google.com>
various: compilation fixes for gcc 4.6

These changes are required to compile successfully with
gcc version 4.6.

The -Wno-address option is applied to some files to
bypass a warning triggered by an rcu macro. The
warning is fixed cleanly upstream, but that fix is too
risky to backport, so it is better to just silence it
this way.

Change-Id: I787ad2db6e649d29874b7b624c2b28f686236466
Signed-off-by: Steve Muckle <smuckle@codeaurora.org>
cifs: silence compiler warnings showing up with gcc-4.7.0

gcc-4.7.0 has started throwing these warnings when building cifs.ko.

  CC [M]  fs/cifs/cifssmb.o
fs/cifs/cifssmb.c: In function ‘CIFSSMBSetCIFSACL’:
fs/cifs/cifssmb.c:3905:9: warning: array subscript is above array bounds [-Warray-bounds]
fs/cifs/cifssmb.c: In function ‘CIFSSMBSetFileInfo’:
fs/cifs/cifssmb.c:5711:8: warning: array subscript is above array bounds [-Warray-bounds]
fs/cifs/cifssmb.c: In function ‘CIFSSMBUnixSetFileInfo’:
fs/cifs/cifssmb.c:6001:25: warning: array subscript is above array bounds [-Warray-bounds]

This patch cleans up the code a bit by using the offsetof macro instead
of the funky "&pSMB->hdr.Protocol" construct.

Change-Id: I07e9f23107483d63811e7e7fd79225bb3898d7e7
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
netfilter: xt_qtaguid: update to msm-3.4

AU_LINUX_ANDROID_JB_MR2.04.03.00.110.011

Change-Id: I8912242c95270f21b0d21dc859c56f0d0342d8c0
add extra free kbytes tunable

Add a userspace visible knob to tell the VM to keep an extra amount
of memory free, by increasing the gap between each zone's min and
low watermarks.

This is useful for realtime applications that call system
calls and have a bound on the number of allocations that happen
in any short time period.  In this application, extra_free_kbytes
would be left at an amount equal to or larger than than the
maximum number of allocations that happen in any burst.

It may also be useful to reduce the memory use of virtual
machines (temporarily?), in a way that does not cause memory
fragmentation like ballooning does.

[ccross]
Revived for use on old kernels where no other solution exists.
The tunable will be removed on kernels that do better at avoiding
direct reclaim.

Change-Id: I765a42be8e964bfd3e2886d1ca85a29d60c3bb3e
Signed-off-by: Rik van Riel<riel@redhat.com>
Signed-off-by: Colin Cross <ccross@android.com>