~tuxonice/linux:vivid

Last commit made on 2016-12-23
Get this branch:
git clone -b vivid https://git.launchpad.net/~tuxonice/linux
Members of TuxOnIce can upload to this branch. Log in for directions.

Branch merges

Branch information

Name:
vivid
Repository:
lp:~tuxonice/linux

Recent commits

ec1a8ce... by Martin Schläffer

Merge tag 'Ubuntu-3.19.0-78.86'

b79e48b... by Martin Schläffer

Merge tag 'Ubuntu-3.19.0-77.85'

ac3a3e4... by Luis Henriques

UBUNTU: Ubuntu-3.19.0-78.86

Signed-off-by: Luis Henriques <email address hidden>

bd4fe51... by Mathias Krause <email address hidden>

proc: prevent accessing /proc/<PID>/environ until it's ready

If /proc/<PID>/environ gets read before the envp[] array is fully set up
in create_{aout,elf,elf_fdpic,flat}_tables(), we might end up trying to
read more bytes than are actually written, as env_start will already be
set but env_end will still be zero, making the range calculation
underflow, allowing to read beyond the end of what has been written.

Fix this as it is done for /proc/<PID>/cmdline by testing env_end for
zero. It is, apparently, intentionally set last in create_*_tables().

This bug was found by the PaX size_overflow plugin that detected the
arithmetic underflow of 'this_len = env_end - (env_start + src)' when
env_end is still zero.

The expected consequence is that userland trying to access
/proc/<PID>/environ of a not yet fully set up process may get
inconsistent data as we're in the middle of copying in the environment
variables.

Fixes: https://forums.grsecurity.net/viewtopic.php?f=3&t=4363
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=116461
Signed-off-by: Mathias Krause <email address hidden>
Cc: Emese Revfy <email address hidden>
Cc: Pax Team <email address hidden>
Cc: Al Viro <email address hidden>
Cc: Mateusz Guzik <email address hidden>
Cc: Alexey Dobriyan <email address hidden>
Cc: Cyrill Gorcunov <email address hidden>
Cc: Jarod Wilson <email address hidden>
Signed-off-by: Andrew Morton <email address hidden>
Signed-off-by: Linus Torvalds <email address hidden>
CVE-2016-7916
(cherry picked from commit 8148a73c9901a8794a50f950083c00ccf97d43b3)
Signed-off-by: Luis Henriques <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Acked-by: Colin Ian King <email address hidden>

e29875d... by Eric W. Biederman

mnt: Add a per mount namespace limit on the number of mounts

CAI Qian <email address hidden> pointed out that the semantics
of shared subtrees make it possible to create an exponentially
increasing number of mounts in a mount namespace.

    mkdir /tmp/1 /tmp/2
    mount --make-rshared /
    for i in $(seq 1 20) ; do mount --bind /tmp/1 /tmp/2 ; done

Will create create 2^20 or 1048576 mounts, which is a practical problem
as some people have managed to hit this by accident.

As such CVE-2016-6213 was assigned.

Ian Kent <email address hidden> described the situation for autofs users
as follows:

> The number of mounts for direct mount maps is usually not very large because of
> the way they are implemented, large direct mount maps can have performance
> problems. There can be anywhere from a few (likely case a few hundred) to less
> than 10000, plus mounts that have been triggered and not yet expired.
>
> Indirect mounts have one autofs mount at the root plus the number of mounts that
> have been triggered and not yet expired.
>
> The number of autofs indirect map entries can range from a few to the common
> case of several thousand and in rare cases up to between 30000 and 50000. I've
> not heard of people with maps larger than 50000 entries.
>
> The larger the number of map entries the greater the possibility for a large
> number of active mounts so it's not hard to expect cases of a 1000 or somewhat
> more active mounts.

So I am setting the default number of mounts allowed per mount
namespace at 100,000. This is more than enough for any use case I
know of, but small enough to quickly stop an exponential increase
in mounts. Which should be perfect to catch misconfigurations and
malfunctioning programs.

For anyone who needs a higher limit this can be changed by writing
to the new /proc/sys/fs/mount-max sysctl.

Tested-by: CAI Qian <email address hidden>
Signed-off-by: "Eric W. Biederman" <email address hidden>
CVE-2016-6213
(backported from commit d29216842a85c7970c536108e093963f02714498)
[ luis: adjust context ]
Signed-off-by: Luis Henriques <email address hidden>
Acked-by: Seth Forshee <email address hidden>
Acked-by: Tim Gardner <email address hidden>

9f35926... by Long Li

hv: do not lose pending heartbeat vmbus packets

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

The host keeps sending heartbeat packets independent of the
guest responding to them. Even though we respond to the heartbeat messages at
interrupt level, we can have situations where there maybe multiple heartbeat
messages pending that have not been responded to. For instance this occurs when the
VM is paused and the host continues to send the heartbeat messages.
Address this issue by draining and responding to all
the heartbeat messages that maybe pending.

Signed-off-by: Long Li <email address hidden>
Signed-off-by: K. Y. Srinivasan <email address hidden>
CC: Stable <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
(cherry picked from commit 407a3aee6ee2d2cb46d9ba3fc380bc29f35d020c)
Signed-off-by: Joseph Salisbury <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Signed-off-by: Luis Henriques <email address hidden>

fbe1eee... by Nicolas Dichtel

ipv6: correctly add local routes when lo goes up

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

The goal of the patch is to fix this scenario:
 ip link add dummy1 type dummy
 ip link set dummy1 up
 ip link set lo down ; ip link set lo up

After that sequence, the local route to the link layer address of dummy1 is
not there anymore.

When the loopback is set down, all local routes are deleted by
addrconf_ifdown()/rt6_ifdown(). At this time, the rt6_info entry still
exists, because the corresponding idev has a reference on it. After the rcu
grace period, dst_rcu_free() is called, and thus ___dst_free(), which will
set obsolete to DST_OBSOLETE_DEAD.

In this case, init_loopback() is called before dst_rcu_free(), thus
obsolete is still sets to something <= 0. So, the function doesn't add the
route again. To avoid that race, let's check the rt6 refcnt instead.

Fixes: 25fb6ca4ed9c ("net IPv6 : Fix broken IPv6 routing table after loopback down-up")
Fixes: a881ae1f625c ("ipv6: don't call addrconf_dst_alloc again when enable lo")
Fixes: 33d99113b110 ("ipv6: reallocate addrconf router for ipv6 address when lo device up")
Reported-by: Francesco Santoro <francesco.santoro@6wind.com>
Reported-by: Samuel Gauthier <samuel.gauthier@6wind.com>
CC: Balakumaran Kannan <email address hidden>
CC: Maruthi Thotad <email address hidden>
CC: Sabrina Dubroca <email address hidden>
CC: Hannes Frederic Sowa <email address hidden>
CC: Weilong Chen <email address hidden>
CC: Gao feng <email address hidden>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <email address hidden>
(cherry picked from commit a220445f9f4382c36a53d8ef3e08165fa27f7e2c)
Signed-off-by: Joseph Salisbury <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Signed-off-by: Luis Henriques <email address hidden>

f50c2b4... by Luis Henriques

UBUNTU: Start new release

Ignore: yes
Signed-off-by: Luis Henriques <email address hidden>

42ddc04... by Martin Schläffer

Merge tag 'Ubuntu-3.19.0-75.83'

a199c86... by Brad Figg

UBUNTU: Ubuntu-3.19.0-77.85

Signed-off-by: Brad Figg <email address hidden>