~ubuntu-kernel/ubuntu/+source/linux/+git/saucy:master

Last commit made on 2014-07-14
Get this branch:
git clone -b master https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/saucy
Members of Ubuntu Kernel Repositories can upload to this branch. Log in for directions.

Branch merges

Branch information

Recent commits

c09d50b... by Luis Henriques

UBUNTU: Ubuntu-3.11.0-26.45

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

6f2919d... by Luis Henriques

l2tp: Privilege escalation in ppp over l2tp sockets

The l2tp call-down to udp_prot.[gs]etsockopt() is entirely broken, as
reported by Sasha, since the socket in question isn't an ip socket, so
when the IP code does either

 struct udp_sock *up = udp_sk(sk);
or
 struct inet_sock *inet = inet_sk(sk);

it basically gets random contents and accesses random kernel memory as a
result.

The suggested patch is trivial, and presumed to not break anything (since
the random udp_sock/inet_sock accesses couldn't really do anything
useful).

This is CVE-2014-4943: an unprivileged user to kernel privilege escalation
when CONFIG_PPPOL2TP is enabled.

Signed-off-by: Marc Deslauriers <email address hidden>
Acked-by: Andy Whitcroft <email address hidden>
CVE-2014-4943
BugLink: http://bugs.launchpad.net/bugs/1341472
Signed-off-by: Luis Henriques <email address hidden>

d14e210... by Luis Henriques

UBUNTU: Start new release

Ignore: yes

0b0a2c1... by Luis Henriques

UBUNTU: Ubuntu-3.11.0-26.44

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

61b7d8b... by Tejun Heo

ptrace,x86: force IRET path after a ptrace_stop()

The 'sysret' fastpath does not correctly restore even all regular
registers, much less any segment registers or reflags values. That is
very much part of why it's faster than 'iret'.

Normally that isn't a problem, because the normal ptrace() interface
catches the process using the signal handler infrastructure, which
always returns with an iret.

However, some paths can get caught using ptrace_event() instead of the
signal path, and for those we need to make sure that we aren't going to
return to user space using 'sysret'. Otherwise the modifications that
may have been done to the register set by the tracer wouldn't
necessarily take effect.

Fix it by forcing IRET path by setting TIF_NOTIFY_RESUME from
arch_ptrace_stop_needed() which is invoked from ptrace_stop().

Signed-off-by: Tejun Heo <email address hidden>
Reported-by: Andy Lutomirski <email address hidden>
Acked-by: Oleg Nesterov <email address hidden>
Suggested-by: Linus Torvalds <email address hidden>
Cc: <email address hidden>
Signed-off-by: Linus Torvalds <email address hidden>
(cherry picked from commit b9cd18de4db3c9ffa7e17b0dc0ca99ed5aa4d43a)
CVE-2014-4699
BugLink: http://bugs.launchpad.net/bugs/1337339
Acked-by: John Johansen <email address hidden>
Acked-by: Andy Whitcroft <email address hidden>
Signed-off-by: Luis Henriques <email address hidden>

7b36634... by Luis Henriques

Revert "x86_64,ptrace: Enforce RIP <= TASK_SIZE_MAX (CVE-2014-4699)"

This reverts commit dff6a181dcb7421fe4e2beed8702b32a1972ef13.

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

This older version of this fix to be replaced with the correct mainline
version.

Acked-by: John Johansen <email address hidden>
Acked-by: Andy Whitcroft <email address hidden>
Signed-off-by: Luis Henriques <email address hidden>

a201ae4... by Luis Henriques

UBUNTU: Start new release

Ignore: yes

b4a7d26... by Luis Henriques

UBUNTU: Merged back Ubuntu-3.11.0-24.42 security release

Merge of security fix for CVE-2014-4699.

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

09670c5... by Luis Henriques

UBUNTU: Ubuntu-3.11.0-24.42

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

dff6a18... by Andrew Lutomirski

x86_64,ptrace: Enforce RIP <= TASK_SIZE_MAX (CVE-2014-4699)

Don't allow ptrace to set RIP to a value that couldn't happen by
ordinary control flow. There are CPU bugs^Wfeatures that can have
interesting effects if RIP is non-canonical.

I didn't make the corresponding x86_32 change, since x86_32 has no
concept of canonical addresses.

putreg32 doesn't need this fix: value is only 32 bits, so it can't
be non-canonical.

Fixes CVE-2014-4699. There are arguably still bugs here, but this
fixes the major issue.

Signed-off-by: Andy Lutomirski <email address hidden>
CVE-2014-4699
BugLink: http://bugs.launchpad.net/bugs/1337339
Acked-by: Andy Whitcroft <email address hidden>
Signed-off-by: John Johansen <email address hidden>
Signed-off-by: Luis Henriques <email address hidden>