net: flow_dissector: fail on evil iph->ihl

We don't validate iph->ihl which may lead a dead loop if we meet a IPIP
skb whose iph->ihl is zero. Fix this by failing immediately when iph->ihl
is evil (less than 5).

This issue were introduced by commit ec5efe7946280d1e84603389a1030ccec0a767ae
(rps: support IPIP encapsulation).

Cc: Eric Dumazet <edumazet@google.com>
Cc: Petr Matousek <pmatouse@redhat.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Merge "net: flow_dissector: fail on evil iph->ihl"
IPA: patch for debugfs to use pr_info

Fix debugfs to use pr_info to print out
routing, filtering rules in  IPA hardware

Change-Id: I29754e0f05fb5d854a7fedc209a01d443dac7eac
Signed-off-by: Ravinder Konka <rkonka@codeaurora.org>
msm: camera: Remove camera_v1 source files

Remove camera_v1 source files since it is not used anymore.

Conflicts:
	drivers/media/platform/msm/Makefile

Change-Id: I1b5a9c8a5f83758b515bb054506cee1132918995
Signed-off-by: Cherian Deepak <dcheri@codeaurora.org>
Signed-off-by: Vignesh Veeramani <quicvignes@codeaurora.org>
Merge "msm: camera: Remove camera_v1 source files"
Merge "IPA: patch for debugfs to use pr_info"
n_tty: Fix n_tty_write crash when echoing in raw mode

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

Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

Change-Id: I9e235db6ec2bb950f26bd8a23f6145dab5dc0a15
Signed-off-by: Natiq Ahmed <mnatiq@codeaurora.org>
Merge "n_tty: Fix n_tty_write crash when echoing in raw mode"
msm_bam_rmnet: Fix potential memory corruption

Usage of legacy string manipulation function sprintf could lead to
memory corruption as the number of bytes to be written to the
destination is not bounded. Replace sprintf with snprintf where the
number of bytes to be written is explicitly specified.

CRs-fixed: 672202
Change-Id: Iab7516ad0e2540eb619fe96e26a3516c7adf86cc
Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Merge "msm_bam_rmnet: Fix potential memory corruption"
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-2015-3153.
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>
Signed-off-by: Divya Sharma <c_shard@codeaurora.org>
Change-Id: I9ee5c8a87cc43c7b1e1dc2796949e7c20c74ddf4
Signed-off-by: Abhinay Reddy Vanipally <avanip@codeaurora.org>
Merge "futex-prevent-requeue-pi-on-same-futex.patch futex: Forbid uaddr == uaddr2 in futex_requeue(..., requeue_pi=1)."