futex-prevent-requeue-pi-on-same-futex.patch futex: Forbid uaddr == uaddr2 in futex_requeue(..., requeue_pi=1)

If uaddr == uaddr2, then we have broken the rule of only requeueing from
a non-pi futex to a pi futex with this call.  If we attempt this, then
dangling pointers may be left for rt_waiter resulting in an exploitable
condition.

This change brings futex_requeue() in line with futex_wait_requeue_pi()
which performs the same check as per commit 6f7b0a2a5c0f ("futex: Forbid
uaddr == uaddr2 in futex_wait_requeue_pi()")

[ tglx: Compare the resulting keys as well, as uaddrs might be
  	different depending on the mapping ]

Fixes CVE-2014-3153.

Change-Id: I5f57f062f735f8a7b29d7a34f4735f9469f671fe
Reported-by: Pinkie Pie
Signed-off-by: Will Drewry <wad@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
msm: mdss: fix the panel color distortion issue for RGB565 format

For the color format RGB565, the pack pattern was set to BGR instead
of RGB, causing the red and blue color swapping on the panel.

CRs-Fixed: 699198

Change-Id: Ib9233a93676e7d5d40f134f9a1657781c631ebdd
Signed-off-by: Xiaoming Zhou <zhoux@codeaurora.org>
mdp3: configure dma source when displaying new frame

During Linux Bootloader to kernel transition, kernel's first call
to overlay_set would reconfigure dma source configurations. This
reconfiguration could happen before vsync but the corresponding
call to overlay_commit would occur after the vsync. This race
condition could cause artifacts to appear on screen. This issue
only occurs on video mode panels.

CRs-Fixed: 699198

Change-Id: I1c1274a9c32cb74276162e74c22ad35afef0eb7c
Signed-off-by: Terence Hampson <thampson@codeaurora.org>
msm: cpp: Validate frame message before manipulating it.

CPP frame message is used to send all frame data
to Microcontroller. It is sent every frame. CPP kernel
driver has to add information to it before transfer it.
The message has to be validated before manipulations.
If it is not valid the message and corresponding frame
are discarded.

Signed-off-by: Manish Poddar <mpoddar@codeaurora.org>
Signed-off-by: Natiq Ahmed <mnatiq@codeaurora.org>
Conflicts:
	drivers/media/platform/msm/camera_v2/pproc/cpp/msm_cpp.c
	drivers/media/platform/msm/camera_v2/pproc/cpp/msm_cpp.h
Change-Id: Ib5b9b5d2e1886d3d671966b693ce212d58e34041
netlink: fix possible spoofing from non-root processes

Non-root user-space processes can send Netlink messages to other
processes that are well-known for being subscribed to Netlink
asynchronous notifications. This allows ilegitimate non-root
process to send forged messages to Netlink subscribers.

The userspace process usually verifies the legitimate origin in
two ways:

a) Socket credentials. If UID != 0, then the message comes from
   some ilegitimate process and the message needs to be dropped.

b) Netlink portID. In general, portID == 0 means that the origin
   of the messages comes from the kernel. Thus, discarding any
   message not coming from the kernel.

However, ctnetlink sets the portID in event messages that has
been triggered by some user-space process, eg. conntrack utility.
So other processes subscribed to ctnetlink events, eg. conntrackd,
know that the event was triggered by some user-space action.

Neither of the two ways to discard ilegitimate messages coming
from non-root processes can help for ctnetlink.

This patch adds capability validation in case that dst_pid is set
in netlink_sendmsg(). This approach is aggressive since existing
applications using any Netlink bus to deliver messages between
two user-space processes will break. Note that the exception is
NETLINK_USERSOCK, since it is reserved for netlink-to-netlink
userspace communication.

Still, if anyone wants that his Netlink bus allows netlink-to-netlink
userspace, then they can set NL_NONROOT_SEND. However, by default,
I don't think it makes sense to allow to use NETLINK_ROUTE to
communicate two processes that are sending no matter what information
that is not related to link/neighbouring/routing. They should be using
NETLINK_USERSOCK instead for that.

Change-Id: I6382c2ecf3dc9ada1f6b7298ebb8bd08453d3a28
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
wcnss: Reset IRIS card before Starting IRIS XO configuration

Set iris_reset bit of PMU CFG register to reset the IRIS
card before Starting IRIS XO configuration.

Change-Id: Id1cfd7e3e3df29919089725b2233c6f95afbbfb5
CRs-Fixed: 664642
Signed-off-by: Hardik Kantilal Patel <hkpatel@codeaurora.org>
Merge "msm: cpp: Validate frame message before manipulating it."
Merge "wcnss: Reset IRIS card before Starting IRIS XO configuration"
Merge "Merge "msm: cpp: Validate frame message before manipulating it.""
Merge "Merge "wcnss: Reset IRIS card before Starting IRIS XO configuration""
Merge "netlink: fix possible spoofing from non-root processes"
Merge "Merge "netlink: fix possible spoofing from non-root processes""
Merge eb63c33053d4deec534ef97ad986c1afa6547efc on remote branch

Change-Id: I7d313f020c5186b0577f094fffc1f9ab18cb9187
Merge "Merge eb63c33053d4deec534ef97ad986c1afa6547efc on remote branch"
Merge "msm: mdss: fix the panel color distortion issue for RGB565 format"
Merge "mdp3: configure dma source when displaying new frame"
USB: dwc3: gadget: Add support for sending zero length packets

Currently driver is not honouring req->zero flag even though
function driver sets this flag. If device has to send IN data back
to host and length is multiple of endpoint maximum packet size, it
should send additional zero length packet at the end to terminate
transfer.

CRs-Fixed: 592504
Change-Id: I5a8aecc504098ed386a9a9d19f4f5b78c911a376
Signed-off-by: Vijayavardhan Vennapusa <vvreddy@codeaurora.org>
Merge "USB: dwc3: gadget: Add support for sending zero length packets"
Merge "futex-prevent-requeue-pi-on-same-futex.patch futex: Forbid uaddr == uaddr2 in futex_requeue(..., requeue_pi=1)"
power: qpnp-charger: reset unsettled flag upon insertion

There could be a potential race between USB removal and userspace
code setting the input current settled property. A state where
USB was removed but input current settled property is set was observed.

Fix this by resetting input current settled property while USB is
inserted as well as USB removed.

Moreover prevent setting of this flag when USB is not present.

CRs-Fixed: 708352
Change-Id: I45196ce5ab0f7ad2b0ccefd33ba9d707f10aea55
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>