1. 08 Mar, 2016 24 commits
  2. 04 Mar, 2016 1 commit
  3. 25 Feb, 2016 1 commit
  4. 23 Feb, 2016 3 commits
  5. 19 Feb, 2016 2 commits
    • Tejun Heo's avatar
      Revert "workqueue: make sure delayed work run in local cpu" · 61f41b6f
      Tejun Heo authored
      commit 041bd12e upstream.
      
      This reverts commit 874bbfe6.
      
      Workqueue used to implicity guarantee that work items queued without
      explicit CPU specified are put on the local CPU.  Recent changes in
      timer broke the guarantee and led to vmstat breakage which was fixed
      by 176bed1d ("vmstat: explicitly schedule per-cpu work on the CPU
      we need it to run on").
      
      vmstat is the most likely to expose the issue and it's quite possible
      that there are other similar problems which are a lot more difficult
      to trigger.  As a preventive measure, 874bbfe6 ("workqueue: make
      sure delayed work run in local cpu") was applied to restore the local
      CPU guarnatee.  Unfortunately, the change exposed a bug in timer code
      which got fixed by 22b886dd ("timers: Use proper base migration in
      add_timer_on()").  Due to code restructuring, the commit couldn't be
      backported beyond certain point and stable kernels which only had
      874bbfe6 started crashing.
      
      The local CPU guarantee was accidental more than anything else and we
      want to get rid of it anyway.  As, with the vmstat case fixed,
      874bbfe6 is causing more problems than it's fixing, it has been
      decided to take the chance and officially break the guarantee by
      reverting the commit.  A debug feature will be added to force foreign
      CPU assignment to expose cases relying on the guarantee and fixes for
      the individual cases will be backported to stable as necessary.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Fixes: 874bbfe6 ("workqueue: make sure delayed work run in local cpu")
      Link: http://lkml.kernel.org/g/20160120211926.GJ10810@quack.suse.cz
      Cc: Mike Galbraith <umgwanakikbuti@gmail.com>
      Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
      Cc: Daniel Bilik <daniel.bilik@neosystem.cz>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Shaohua Li <shli@fb.com>
      Cc: Sasha Levin <sasha.levin@oracle.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Daniel Bilik <daniel.bilik@neosystem.cz>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Cc: Michal Hocko <mhocko@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      61f41b6f
    • Linus Torvalds's avatar
      vmstat: explicitly schedule per-cpu work on the CPU we need it to run on · 32083def
      Linus Torvalds authored
      commit 176bed1d upstream.
      
      The vmstat code uses "schedule_delayed_work_on()" to do the initial
      startup of the delayed work on the right CPU, but then once it was
      started it would use the non-cpu-specific "schedule_delayed_work()" to
      re-schedule it on that CPU.
      
      That just happened to schedule it on the same CPU historically (well, in
      almost all situations), but the code _requires_ this work to be per-cpu,
      and should say so explicitly rather than depend on the non-cpu-specific
      scheduling to schedule on the current CPU.
      
      The timer code is being changed to not be as single-minded in always
      running things on the calling CPU.
      
      See also commit 874bbfe6 ("workqueue: make sure delayed work run in
      local cpu") that for now maintains the local CPU guarantees just in case
      there are other broken users that depended on the accidental behavior.
      
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Tejun Heo <tj@kernel.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      [ kamal: backport to 3.19-stable: use queue_delayed_work_on() ]
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      32083def
  6. 12 Feb, 2016 2 commits
  7. 11 Feb, 2016 7 commits
    • Yevgeny Pats's avatar
      KEYS: Fix keyring ref leak in join_session_keyring() · 50fcdf69
      Yevgeny Pats authored
      commit 23567fd0 upstream.
      
      This fixes CVE-2016-0728.
      
      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:
      
      	#include <stddef.h>
      	#include <stdio.h>
      	#include <sys/types.h>
      	#include <keyutils.h>
      
      	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: default avatarYevgeny Pats <yevgeny@perception-point.io>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarDon Zickus <dzickus@redhat.com>
      Acked-by: default avatarPrarit Bhargava <prarit@redhat.com>
      Acked-by: default avatarJarod Wilson <jarod@redhat.com>
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      50fcdf69
    • David Howells's avatar
      ASN.1: Fix non-match detection failure on data overrun · b221d1e0
      David Howells authored
      commit 0d62e9dd upstream.
      
      If the ASN.1 decoder is asked to parse a sequence of objects, non-optional
      matches get skipped if there's no more data to be had rather than a
      data-overrun error being reported.
      
      This is due to the code segment that decides whether to skip optional
      matches (ie. matches that could get ignored because an element is marked
      OPTIONAL in the grammar) due to a lack of data also skips non-optional
      elements if the data pointer has reached the end of the buffer.
      
      This can be tested with the data decoder for the new RSA akcipher algorithm
      that takes three non-optional integers.  Currently, it skips the last
      integer if there is insufficient data.
      
      Without the fix, #defining DEBUG in asn1_decoder.c will show something
      like:
      
      	next_op: pc=0/13 dp=0/270 C=0 J=0
      	- match? 30 30 00
      	- TAG: 30 266 CONS
      	next_op: pc=2/13 dp=4/270 C=1 J=0
      	- match? 02 02 00
      	- TAG: 02 257
      	- LEAF: 257
      	next_op: pc=5/13 dp=265/270 C=1 J=0
      	- match? 02 02 00
      	- TAG: 02 3
      	- LEAF: 3
      	next_op: pc=8/13 dp=270/270 C=1 J=0
      	next_op: pc=11/13 dp=270/270 C=1 J=0
      	- end cons t=4 dp=270 l=270/270
      
      The next_op line for pc=8/13 should be followed by a match line.
      
      This is not exploitable for X.509 certificates by means of shortening the
      message and fixing up the ASN.1 CONS tags because:
      
       (1) The relevant records being built up are cleared before use.
      
       (2) If the message is shortened sufficiently to remove the public key, the
           ASN.1 parse of the RSA key will fail quickly due to a lack of data.
      
       (3) Extracted signature data is either turned into MPIs (which cope with a
           0 length) or is simpler integers specifying algoritms and suchlike
           (which can validly be 0); and
      
       (4) The AKID and SKID extensions are optional and their removal is handled
           without risking passing a NULL to asymmetric_key_generate_id().
      
       (5) If the certificate is truncated sufficiently to remove the subject,
           issuer or serialNumber then the ASN.1 decoder will fail with a 'Cons
           stack underflow' return.
      
      This is not exploitable for PKCS#7 messages by means of removal of elements
      from such a message from the tail end of a sequence:
      
       (1) Any shortened X.509 certs embedded in the PKCS#7 message are survivable
           as detailed above.
      
       (2) The message digest content isn't used if it shows a NULL pointer,
           similarly, the authattrs aren't used if that shows a NULL pointer.
      
       (3) A missing signature results in a NULL MPI - which the MPI routines deal
           with.
      
       (4) If data is NULL, it is expected that the message has detached content and
           that is handled appropriately.
      
       (5) If the serialNumber is excised, the unconditional action associated
           with it will pick up the containing SEQUENCE instead, so no NULL
           pointer will be seen here.
      
           If both the issuer and the serialNumber are excised, the ASN.1 decode
           will fail with an 'Unexpected tag' return.
      
           In either case, there's no way to get to asymmetric_key_generate_id()
           with a NULL pointer.
      
       (6) Other fields are decoded to simple integers.  Shortening the message
           to omit an algorithm ID field will cause checks on this to fail early
           in the verification process.
      
      This can also be tested by snipping objects off of the end of the ASN.1 stream
      such that mandatory tags are removed - or even from the end of internal
      SEQUENCEs.  If any mandatory tag is missing, the error EBADMSG *should* be
      produced.  Without this patch ERANGE or ENOPKG might be produced or the parse
      may apparently succeed, perhaps with ENOKEY or EKEYREJECTED being produced
      later, depending on what gets snipped.
      
      Just snipping off the final BIT_STRING or OCTET_STRING from either sample
      should be a start since both are mandatory and neither will cause an EBADMSG
      without the patches
      Reported-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Tested-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Reviewed-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      [ kamal: backport to 3.19-stable: context ]
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      b221d1e0
    • Vladis Dronov's avatar
      [media] usbvision: fix crash on detecting device with invalid configuration · 36c339ae
      Vladis Dronov authored
      commit fa52bd50 upstream.
      
      The usbvision driver crashes when a specially crafted usb device with invalid
      number of interfaces or endpoints is detected. This fix adds checks that the
      device has proper configuration expected by the driver.
      Reported-by: default avatarRalf Spenneberg <ralf@spenneberg.net>
      Signed-off-by: default avatarVladis Dronov <vdronov@redhat.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      36c339ae
    • Alexey Khoroshilov's avatar
      [media] usbvision: fix leak of usb_dev on failure paths in usbvision_probe() · c1d8a27d
      Alexey Khoroshilov authored
      commit afd270d1 upstream.
      
      There is no usb_put_dev() on failure paths in usbvision_probe().
      
      Found by Linux Driver Verification project (linuxtesting.org).
      Signed-off-by: default avatarAlexey Khoroshilov <khoroshilov@ispras.ru>
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      c1d8a27d
    • Oliver Neukum's avatar
      [media] usbvision fix overflow of interfaces array · 5a5c874e
      Oliver Neukum authored
      commit 588afcc1 upstream.
      
      This fixes the crash reported in:
      http://seclists.org/bugtraq/2015/Oct/35
      The interface number needs a sanity check.
      Signed-off-by: default avatarOliver Neukum <oneukum@suse.com>
      Cc: Vladis Dronov <vdronov@redhat.com>
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      5a5c874e
    • Madhavan Srinivasan's avatar
      powerpc/perf: Remove PPMU_HAS_SSLOT flag for Power8 · 697995c2
      Madhavan Srinivasan authored
      commit 370f06c8 upstream.
      
      Commit 7a786832 ("powerpc/perf: Add an explict flag indicating
      presence of SLOT field") introduced the PPMU_HAS_SSLOT flag to remove
      the assumption that MMCRA[SLOT] was present when PPMU_ALT_SIPR was not
      set.
      
      That commit's changelog also mentions that Power8 does not support
      MMCRA[SLOT]. However when the Power8 PMU support was merged, it
      errnoeously included the PPMU_HAS_SSLOT flag.
      
      So remove PPMU_HAS_SSLOT from the Power8 flags.
      
      mpe: On systems where MMCRA[SLOT] exists, the field occupies bits 37:39
      (IBM numbering). On Power8 bit 37 is reserved, and 38:39 overlap with
      the high bits of the Threshold Event Counter Mantissa. I am not aware of
      any published events which use the threshold counting mechanism, which
      would cause the mantissa bits to be set. So in practice this bug is
      unlikely to trigger.
      
      Fixes: e05b9b9e ("powerpc/perf: Power8 PMU support")
      Signed-off-by: default avatarMadhavan Srinivasan <maddy@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      697995c2
    • Jiri Olsa's avatar
      perf hists: Fix HISTC_MEM_DCACHELINE width setting · 0e6a04f9
      Jiri Olsa authored
      commit 0805909f upstream.
      
      Set correct width for unresolved mem_dcacheline addr.
      Signed-off-by: default avatarJiri Olsa <jolsa@kernel.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Fixes: 9b32ba71 ("perf tools: Add dcacheline sort")
      Link: http://lkml.kernel.org/r/1453290995-18485-3-git-send-email-jolsa@kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      0e6a04f9