~ubuntu-kernel/ubuntu/+source/linux/+git/lucid:master-next

Branch merges

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related charm recipes

b777ece... by Luis Henriques on 2015-04-28

UBUNTU: Ubuntu-2.6.32-74.142

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

36e221d... by Jann Horn on 2015-04-19

fs: take i_mutex during prepare_binprm for set[ug]id executables

This prevents a race between chown() and execve(), where chowning a
setuid-user binary to root would momentarily make the binary setuid
root.

This patch was mostly written by Linus Torvalds.

Signed-off-by: Jann Horn <email address hidden>
Signed-off-by: Linus Torvalds <email address hidden>
(backported from commit 8b01fc86b9f425899f8a3a8fc1c47d73c2c20543)
[ luis: backport to Lucid:
  - replaced kuid_t/kgid_t by uid_t/gid_t
  - replaced READ_ONCE() by ACCESS_ONCE()
  - replaced file_inode() by bprm->file->f_path.dentry->d_inode
  - dropped user_ns bits and task_no_new_privs() ]
CVE-2015-3339
BugLink: https://bugs.launchpad.net/bugs/1447373
Acked-by: Seth Forshee <email address hidden>
Acked-by: John Johansen <email address hidden>
Signed-off-by: Luis Henriques <email address hidden>

995ddc7... by Luis Henriques on 2015-04-27

UBUNTU: Start new release

Ignore: yes

c5016e8... by Luis Henriques on 2015-03-09

UBUNTU: Ubuntu-2.6.32-73.141

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

d2e24c3... by Shachar Raindel on 2015-01-04

IB/core: Prevent integer overflow in ib_umem_get address arithmetic

Properly verify that the resulting page aligned end address is larger
than both the start address and the length of the memory area
requested.

Both the start and length arguments for ib_umem_get are controlled by
the user. A misbehaving user can provide values which will cause an
integer overflow when calculating the page aligned end address.

This overflow can cause also miscalculation of the number of pages
mapped, and additional logic issues.

Issue: 470602
Change-Id: Iee88441db454af291fc5a376009d840603398d23
Signed-off-by: Shachar Raindel <email address hidden>
Signed-off-by: Jack Morgenstein <email address hidden>
Signed-off-by: Or Gerlitz <email address hidden>
Signed-off-by: John Johansen <email address hidden>
CVE-2015-8159
BugLink: http://bugs.launchpad.net/bugs/1413741
Signed-off-by: Luis Henriques <email address hidden>

3b0f03e... by Luis Henriques on 2015-03-09

UBUNTU: Start new release

Ignore: yes

4301273... by Seth Forshee on 2015-02-09

UBUNTU: Ubuntu-2.6.32-73.140

Signed-off-by: Seth Forshee <email address hidden>

a5619db... by Kamal Mostafa on 2015-01-16

UBUNTU: [Packaging] force "dpkg-source -I -i" behavior

Signed-off-by: Kamal Mostafa <email address hidden>

af6ad53... by Sasha Levin on 2015-01-14

KEYS: close race between key lookup and freeing

When a key is being garbage collected, it's key->user would get put before
the ->destroy() callback is called, where the key is removed from it's
respective tracking structures.

This leaves a key hanging in a semi-invalid state which leaves a window open
for a different task to try an access key->user. An example is
find_keyring_by_name() which would dereference key->user for a key that is
in the process of being garbage collected (where key->user was freed but
->destroy() wasn't called yet - so it's still present in the linked list).

This would cause either a panic, or corrupt memory.

Fixes CVE-2014-9529.

Signed-off-by: Sasha Levin <email address hidden>
Signed-off-by: David Howells <email address hidden>
(backported from commit a3a8784454692dd72e5d5d34dcdab17b4420e74c)
CVE-2014-9529
BugLink: http://bugs.launchpad.net/bugs/1409048
Signed-off-by: Luis Henriques <email address hidden>
Acked-by: Seth Forshee <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Signed-off-by: Brad Figg <email address hidden>

142adf3... by Jan Kara <email address hidden> on 2015-01-14

isofs: Fix unchecked printing of ER records

We didn't check length of rock ridge ER records before printing them.
Thus corrupted isofs image can cause us to access and print some memory
behind the buffer with obvious consequences.

Reported-and-tested-by: Carl Henrik Lunde <email address hidden>
CC: <email address hidden>
Signed-off-by: Jan Kara <email address hidden>
(cherry picked from commit 4e2024624e678f0ebb916e6192bd23c1f9fdf696)
CVE-2014-9584
BugLink: http://bugs.launchpad.net/bugs/1409808
Signed-off-by: Luis Henriques <email address hidden>
Acked-by: Seth Forshee <email address hidden>
Acked-by: Colin King <email address hidden>
Signed-off-by: Brad Figg <email address hidden>