~tuxonice/linux:xenial-4.3

Branch merges

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related charm recipes

0b9c89b... by Martin Schläffer on 2016-01-22

Merge tag 'Ubuntu-4.3.0-7.18'

3446533... by Martin Schläffer on 2016-01-19

Merge tag 'Ubuntu-4.3.0-6.17'

50ecba5... by Tim Gardner on 2016-01-19

UBUNTU: Ubuntu-4.3.0-7.18

Signed-off-by: Tim Gardner <email address hidden>

5b6cce0... by Andy Whitcroft on 2016-01-19

UBUNTU: [Config] s390x -- the kernel provides ppp-modules such as there are

Signed-off-by: Andy Whitcroft <email address hidden>

182fc6c... by Yevgeny on 2016-01-11

KEYS: Fix keyring ref leak in join_session_keyring()

If a thread is asked to join as a session keyring the keyring that's already
set as its session, we leak a keyring reference.

This can be tested with the following program:

int main(int argc, const char *argv[])
{
 int i = 0;
 key_serial_t serial;

 serial = keyctl(KEYCTL_JOIN_SESSION_KEYRING,
   "leaked-keyring");
 if (serial < 0) {
  perror("keyctl");
  return -1;
 }

 if (keyctl(KEYCTL_SETPERM, serial,
     KEY_POS_ALL | KEY_USR_ALL) < 0) {
  perror("keyctl");
  return -1;
 }

 for (i = 0; i < 100; i++) {
  serial = keyctl(KEYCTL_JOIN_SESSION_KEYRING,
    "leaked-keyring");
  if (serial < 0) {
   perror("keyctl");
   return -1;
  }
 }

 return 0;
}

If, after the program has run, there something like the following line in
/proc/keys:

3f3d898f I--Q--- 100 perm 3f3f0000 0 0 keyring leaked-keyring: empty

with a usage count of 100 * the number of times the program has been run,
then the kernel is malfunctioning. If leaked-keyring has zero usages or
has been garbage collected, then the problem is fixed.

Reported-by: Yevgeny Pats <email address hidden>
Signed-off-by: David Howells <email address hidden>
BugLink: https://bugs.launchpad.net/bugs/1534887
CVE-2016-0728
Acked-by: Steve Beattie <email address hidden>
Acked-by: Andy Whitcroft <email address hidden>
Signed-off-by: Luis Henriques <email address hidden>
Signed-off-by: Andy Whitcroft <email address hidden>

e8bcabb... by Martin Schläffer on 2016-01-14

Merge tag 'Ubuntu-4.3.0-5.16'

Conflicts:
 debian.master/config/armhf/config.flavour.generic-lpae-tuxonice
 debian.master/config/armhf/config.flavour.generic-tuxonice

c250300... by Tim Gardner on 2016-01-12

UBUNTU: Start new release

Ignore: yes
Signed-off-by: Tim Gardner <email address hidden>

2a8b8bd... by Tim Gardner on 2016-01-11

UBUNTU: Ubuntu-4.3.0-6.17

Signed-off-by: Tim Gardner <email address hidden>

773dc56... by Guilherme G. Piccoli on 2016-01-10

UBUNTU: SAUCE: powerpc/eeh: Validate arch in eeh_add_device_early()

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

Commit 89a51df5ab1d ("powerpc/eeh: Fix crash in eeh_add_device_early() on Cell")
added a check on function eeh_add_device_early(): since in Cell arch eeh_ops
is NULL, that code used to crash on Cell. The commit's approach was validate
if EEH was available by checking the result of function eeh_enabled().

Since the function eeh_add_device_early() is used to perform EEH
initialization in devices added later on the system, like in hotplug/DLPAR
scenarios, we might reach a case in which no PCI devices are present on boot
and so EEH is not initialized. Then, if a device is added via DLPAR for
example, eeh_add_device_early() fails because eeh_enabled() is false.

We can hit a kernel oops on pSeries arch if eeh_add_device_early() fails:
if we have no PCI devices on machine at boot time, and then we add a PCI device
via DLPAR operation, the function query_ddw() triggers the oops on NULL pointer
dereference in the line "cfg_addr = edev->config_addr;". It happens because
config_addr in edev is NULL, since the function eeh_add_device_early() was not
completed successfully.

This patch just changes the way the arch checking is done in function
eeh_add_device_early(): we use no more eeh_enabled(), but instead we check the
running architecture by using the macro machine_is(). If we are running on
pSeries or PowerNV, the EEH mechanism can be enabled; otherwise, we bail out
the function. This way, we don't enable EEH on Cell and we don't hit the oops
on DLPAR either.

Fixes: 89a51df5ab1d ("powerpc/eeh: Fix crash in eeh_add_device_early() on Cell")
Signed-off-by: Guilherme G. Piccoli <email address hidden>
Signed-off-by: Tim Gardner <email address hidden>

f700a3c... by Tim Gardner on 2016-01-11

UBUNTU: [Config] CONFIG_VIRTIO_BLK=y, CONFIG_VIRTIO_NET=y for s390

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

Change these config settings to be consistent with all of the other
architectures.

Signed-off-by: Tim Gardner <email address hidden>