UBUNTU: Start new release

Signed-off-by: Brad Figg <brad.figg@canonical.com>
UBUNTU: SAUCE: Fix compat_sys_recvmsg on x32 archs

BugLink: http://bugs.launchpad.net/bugs/1274349

Reported by pageexec

asmlinkage long compat_sys_recvmmsg(int fd, struct compat_mmsghdr __user *mmsg,
                                    unsigned int vlen, unsigned int flags,
                                    struct compat_timespec __user *timeout)
{
        int datagrams;
        struct timespec ktspec;

        if (flags & MSG_CMSG_COMPAT)
                return -EINVAL;

        if (COMPAT_USE_64BIT_TIME)
                return __sys_recvmmsg(fd, (struct mmsghdr __user *)mmsg, vlen,
                                      flags | MSG_CMSG_COMPAT,
                                      (struct timespec *) timeout);
/*...*/

The timeout pointer parameter is provided by userland (hence the
__user annotation) but for x32 syscalls it's simply cast to a kernel
pointer and is passed to __sys_recvmmsg which will eventually directly
dereference it for both reading and writing. Other callers to
__sys_recvmmsg properly copy from userland to the kernel first.

The impact is a sort of arbitrary kernel write-where-what primitive by
unprivileged users where the to-be-written area must contain valid
timespec data initially (the first 64 bit long field must be positive
and the second one must be < 1G).

The bug was introduced by commit
http://git.kernel.org/linus/ee4fa23c4b (other uses of
COMPAT_USE_64BIT_TIME seem fine) and should affect all kernels since
3.4 (and perhaps vendor kernels if they backported x32 support along
with this code). Note that CONFIG_X86_X32_ABI gets enabled at build
time and only if CONFIG_X86_X32 is enabled and ld can build x32
executables.

Signed-off-by: PaX Team <pageexec@freemail.hu>
Signed-off-by: John Johansen <john.johansen@canonical.com>
UBUNTU: Ubuntu-3.11.0-15.25

Signed-off-by: Brad Figg <brad.figg@canonical.com>
UBUNTU: Merge of security fix for CVE-2013-0038

Signed-off-by: Brad Figg <brad.figg@canonical.com>
UBUNTU: Start new release

Ignore: yes

Signed-off-by: Brad Figg <brad.figg@canonical.com>
Revert "UBUNTU: SAUCE: Fix compat_sys_recvmsg on x32 archs"

This reverts commit 8c57646584aab87099d0dc69785ce3e2b2b3b626. There is a
different commit applied to upstream to address this same issue.
UBUNTU: [Upstream] x86, x32: Correct invalid use of user timespec in the kernel

This patch is the upstream revision of the patch pushed out for
CVE-2013-0038. It needs to be applied to

    saucy: linux
  precise: linux-lts-raring linux-lts-saucy

The x32 case for the recvmsg() timout handling is broken:

http://bugs.launchpad.net/bugs/1274754

  asmlinkage long compat_sys_recvmmsg(int fd, struct compat_mmsghdr __user *mmsg,
                                      unsigned int vlen, unsigned int flags,
                                      struct compat_timespec __user *timeout)
  {
          int datagrams;
          struct timespec ktspec;

          if (flags & MSG_CMSG_COMPAT)
                  return -EINVAL;

          if (COMPAT_USE_64BIT_TIME)
                  return __sys_recvmmsg(fd, (struct mmsghdr __user *)mmsg, vlen,
                                        flags | MSG_CMSG_COMPAT,
                                        (struct timespec *) timeout);
          ...

The timeout pointer parameter is provided by userland (hence the __user
annotation) but for x32 syscalls it's simply cast to a kernel pointer
and is passed to __sys_recvmmsg which will eventually directly
dereference it for both reading and writing.  Other callers to
__sys_recvmmsg properly copy from userland to the kernel first.

The bug was introduced by commit ee4fa23c4bfc ("compat: Use
COMPAT_USE_64BIT_TIME in net/compat.c") and should affect all kernels
since 3.4 (and perhaps vendor kernels if they backported x32 support
along with this code).

Note that CONFIG_X86_X32_ABI gets enabled at build time and only if
CONFIG_X86_X32 is enabled and ld can build x32 executables.

Other uses of COMPAT_USE_64BIT_TIME seem fine.

This addresses CVE-2014-0038.

Signed-off-by: PaX Team <pageexec@freemail.hu>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Cc: <stable@vger.kernel.org> # v3.4+
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry-picked from commit 2def2ef2ae5f3990aabdbe8a755911902707d268)
Signed-off-by: John Johansen <john.johansen@canonical.com>
Signed-off-by: Brad Figg <brad.figg@canonical.com>
UBUNTU: Ubuntu-3.11.0-17.31

Signed-off-by: Brad Figg <brad.figg@canonical.com>
mptcp: Correctly check for waiting application before updating sndbuf

In tcp_check_space, we circumvent the check for sk_socket and
SOCK_NOSPACE in order to force the subflow's call to sk_write_space.

However, tcp_new_space does a call to tcp_should_expand_sndbuf before
calling sk_write_space. So, in mptcp_should_expand_sndbuf, we can do the
correct check again. That way we avoid to needlessly increase the
send-buffer.

Reported-by: Mikel Jimenez <mikeljim@fb.com>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Do not try to establish new subflows if the master is not yet fully established

When creating a new MPTCP-session, we call mptcp_v4_add_raddress to
properly add the initial remote address to our address-list. This sets
list_rcvd to 1 and will later trigger the creation of a new subflow.

However, we are not even sure if the master is actually fully
established. We cannot start the creation of new subflows prior to this.

This patch checks for the master being fully established before
attempting to act on the new remote address-event.

Reported-by: Ardhan Madras <ardhan@rocksis.net>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Change sk_shutdown when combining dfin with sub-fin

Because, this is just like a call to shutdown(). So, we have to set
sk_shutdown correctly.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Force close a subflow when resetting fallbacked MPTCP session

We have to force the closure of the subflow, because the connection is
completly dead now.

Reported-by: Ardhan Madras <ardhan@rocksis.net>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Fullmesh pathmanager: Fix event-handling in case of "multipath on"

If the "multipath on"-flag changes, we schedule a MOD-event. Later when
parsing the sockets we thus will never trigger the creation of new
subflows.

This patch transforms the MOD-event into an ADD-event so that it gets
handled correctly later on.

Reported-by: Kristian Walsh <kristian.walsh@quantumvpn.com>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Select correct ack-sock when removing subflows.

We must make sure that the ack-sock we select is the one who is still
operational. We achieve this by checking the pf-flag of the subflow when
choosing the ack-sock. In order to make sure that the pf-flag is set, we
call mptcp_reinject_data before calling update_remove_addr so that the
correct ack-sock is chosen.

Reported-by: John Ronan <jpronans@gmail.com>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Don't reinject empty data-fins on the same subflow

An empty data-fin might get lost on a subflow. If it would have hold
data, then the subflow-level RTO would have reinjected that data-fin on
another subflow and set the tp->pf flag to 1. This would then have
prevented this same subflow to be selected twice for the data-fin.

However, currently mptcp_dont_reinject will always select the same
subflow for empty data-fins even if it has been lost.

We must make sure that the empty data-fin is sent in a round-robin
fashion in case of RTOs as it is done for regular data.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
New stable release v0.88.8

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Merge remote-tracking branch 'saucy/master' into mptcp_trunk_saucy

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>

Conflicts:
	debian.master/changelog
New Saucy Release

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>