1. 09 Mar, 2016 4 commits
  2. 04 Mar, 2016 1 commit
  3. 29 Feb, 2016 1 commit
  4. 23 Feb, 2016 4 commits
    • Eric W. Biederman's avatar
      umount: Do not allow unmounting rootfs. · c3e4992d
      Eric W. Biederman authored
      commit da362b09 upstream.
      
      Andrew Vagin <avagin@parallels.com> writes:
      
      > #define _GNU_SOURCE
      > #include <sys/types.h>
      > #include <sys/stat.h>
      > #include <fcntl.h>
      > #include <sched.h>
      > #include <unistd.h>
      > #include <sys/mount.h>
      >
      > int main(int argc, char **argv)
      > {
      > 	int fd;
      >
      > 	fd = open("/proc/self/ns/mnt", O_RDONLY);
      > 	if (fd < 0)
      > 	   return 1;
      > 	   while (1) {
      > 	   	 if (umount2("/", MNT_DETACH) ||
      > 		        setns(fd, CLONE_NEWNS))
      > 					break;
      > 					}
      >
      > 					return 0;
      > }
      >
      > root@ubuntu:/home/avagin# gcc -Wall nsenter.c -o nsenter
      > root@ubuntu:/home/avagin# strace ./nsenter
      > execve("./nsenter", ["./nsenter"], [/* 22 vars */]) = 0
      > ...
      > open("/proc/self/ns/mnt", O_RDONLY)     = 3
      > umount("/", MNT_DETACH)                 = 0
      > setns(3, 131072)                        = 0
      > umount("/", MNT_DETACH
      >
      causes:
      
      > [  260.548301] ------------[ cut here ]------------
      > [  260.550941] kernel BUG at /build/buildd/linux-3.13.0/fs/pnode.c:372!
      > [  260.552068] invalid opcode: 0000 [#1] SMP
      > [  260.552068] Modules linked in: xt_CHECKSUM iptable_mangle xt_tcpudp xt_addrtype xt_conntrack ipt_MASQUERADE iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack bridge stp llc dm_thin_pool dm_persistent_data dm_bufio dm_bio_prison iptable_filter ip_tables x_tables crct10dif_pclmul crc32_pclmul ghash_clmulni_intel binfmt_misc nfsd auth_rpcgss nfs_acl aesni_intel nfs lockd aes_x86_64 sunrpc fscache lrw gf128mul glue_helper ablk_helper cryptd serio_raw ppdev parport_pc lp parport btrfs xor raid6_pq libcrc32c psmouse floppy
      > [  260.552068] CPU: 0 PID: 1723 Comm: nsenter Not tainted 3.13.0-30-generic #55-Ubuntu
      > [  260.552068] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
      > [  260.552068] task: ffff8800376097f0 ti: ffff880074824000 task.ti: ffff880074824000
      > [  260.552068] RIP: 0010:[<ffffffff811e9483>]  [<ffffffff811e9483>] propagate_umount+0x123/0x130
      > [  260.552068] RSP: 0018:ffff880074825e98  EFLAGS: 00010246
      > [  260.552068] RAX: ffff88007c741140 RBX: 0000000000000002 RCX: ffff88007c741190
      > [  260.552068] RDX: ffff88007c741190 RSI: ffff880074825ec0 RDI: ffff880074825ec0
      > [  260.552068] RBP: ffff880074825eb0 R08: 00000000000172e0 R09: ffff88007fc172e0
      > [  260.552068] R10: ffffffff811cc642 R11: ffffea0001d59000 R12: ffff88007c741140
      > [  260.552068] R13: ffff88007c741140 R14: ffff88007c741140 R15: 0000000000000000
      > [  260.552068] FS:  00007fd5c7e41740(0000) GS:ffff88007fc00000(0000) knlGS:0000000000000000
      > [  260.552068] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      > [  260.552068] CR2: 00007fd5c7968050 CR3: 0000000070124000 CR4: 00000000000406f0
      > [  260.552068] Stack:
      > [  260.552068]  0000000000000002 0000000000000002 ffff88007c631000 ffff880074825ed8
      > [  260.552068]  ffffffff811dcfac ffff88007c741140 0000000000000002 ffff88007c741160
      > [  260.552068]  ffff880074825f38 ffffffff811dd12b ffffffff811cc642 0000000075640000
      > [  260.552068] Call Trace:
      > [  260.552068]  [<ffffffff811dcfac>] umount_tree+0x20c/0x260
      > [  260.552068]  [<ffffffff811dd12b>] do_umount+0x12b/0x300
      > [  260.552068]  [<ffffffff811cc642>] ? final_putname+0x22/0x50
      > [  260.552068]  [<ffffffff811cc849>] ? putname+0x29/0x40
      > [  260.552068]  [<ffffffff811dd88c>] SyS_umount+0xdc/0x100
      > [  260.552068]  [<ffffffff8172aeff>] tracesys+0xe1/0xe6
      > [  260.552068] Code: 89 50 08 48 8b 50 08 48 89 02 49 89 45 08 e9 72 ff ff ff 0f 1f 44 00 00 4c 89 e6 4c 89 e7 e8 f5 f6 ff ff 48 89 c3 e9 39 ff ff ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 90 66 66 66 66 90 55 b8 01
      > [  260.552068] RIP  [<ffffffff811e9483>] propagate_umount+0x123/0x130
      > [  260.552068]  RSP <ffff880074825e98>
      > [  260.611451] ---[ end trace 11c33d85f1d4c652 ]--
      
      Which in practice is totally uninteresting.  Only the global root user can
      do it, and it is just a stupid thing to do.
      
      However that is no excuse to allow a silly way to oops the kernel.
      
      We can avoid this silly problem by setting MNT_LOCKED on the rootfs
      mount point and thus avoid needing any special cases in the unmount
      code.
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      c3e4992d
    • Andrey Konovalov's avatar
      ALSA: usb-audio: avoid freeing umidi object twice · 5f8b3821
      Andrey Konovalov authored
      commit 07d86ca9 upstream.
      
      The 'umidi' object will be free'd on the error path by snd_usbmidi_free()
      when tearing down the rawmidi interface. So we shouldn't try to free it
      in snd_usbmidi_create() after having registered the rawmidi interface.
      
      Found by KASAN.
      Signed-off-by: default avatarAndrey Konovalov <andreyknvl@gmail.com>
      Acked-by: default avatarClemens Ladisch <clemens@ladisch.de>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      5f8b3821
    • Ryan Ware's avatar
      EVM: Use crypto_memneq() for digest comparisons · f5da0075
      Ryan Ware authored
      commit 613317bd upstream.
      
      This patch fixes vulnerability CVE-2016-2085.  The problem exists
      because the vm_verify_hmac() function includes a use of memcmp().
      Unfortunately, this allows timing side channel attacks; specifically
      a MAC forgery complexity drop from 2^128 to 2^12.  This patch changes
      the memcmp() to the cryptographically safe crypto_memneq().
      Reported-by: default avatarXiaofei Rex Guo <xiaofei.rex.guo@intel.com>
      Signed-off-by: default avatarRyan Ware <ware@linux.intel.com>
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      f5da0075
    • Hariprasad S's avatar
      iw_cxgb3: Fix incorrectly returning error on success · 0ab823f1
      Hariprasad S authored
      commit 67f1aee6 upstream.
      
      The cxgb3_*_send() functions return NET_XMIT_ values, which are
      positive integers values. So don't treat positive return values
      as an error.
      Signed-off-by: default avatarSteve Wise <swise@opengridcomputing.com>
      Signed-off-by: default avatarHariprasad Shenai <hariprasad@chelsio.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      0ab823f1
  5. 22 Feb, 2016 2 commits
    • Tejun Heo's avatar
      Revert "workqueue: make sure delayed work run in local cpu" · 5e3652f7
      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>
      5e3652f7
    • Linus Torvalds's avatar
      vmstat: explicitly schedule per-cpu work on the CPU we need it to run on · c621c5b5
      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.
      
      js: 3.12 backport
      
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Mike Galbraith <mgalbraith@suse.com>
      Cc: Michal Hocko <mhocko@suse.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      [ kamal: backport to 3.13-stable: use queue_delayed_work_on() ]
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      c621c5b5
  6. 16 Feb, 2016 1 commit
  7. 10 Feb, 2016 24 commits
  8. 09 Feb, 2016 3 commits
    • David Howells's avatar
      ASN.1: Fix non-match detection failure on data overrun · 07b60a1e
      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>
      07b60a1e
    • Vladis Dronov's avatar
      USB: serial: visor: fix crash on detecting device without write_urbs · 31fed5d5
      Vladis Dronov authored
      commit cb323213 upstream.
      
      The visor driver crashes in clie_5_attach() when a specially crafted USB
      device without bulk-out endpoint is detected. This fix adds a check 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>
      Fixes: cfb8da8f ("USB: visor: fix initialisation of UX50/TH55 devices")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      31fed5d5
    • Peter Hurley's avatar
      tty: Fix unsafe ldisc reference via ioctl(TIOCGETD) · b333fc07
      Peter Hurley authored
      commit 5c17c861 upstream.
      
      ioctl(TIOCGETD) retrieves the line discipline id directly from the
      ldisc because the line discipline id (c_line) in termios is untrustworthy;
      userspace may have set termios via ioctl(TCSETS*) without actually
      changing the line discipline via ioctl(TIOCSETD).
      
      However, directly accessing the current ldisc via tty->ldisc is
      unsafe; the ldisc ptr dereferenced may be stale if the line discipline
      is changing via ioctl(TIOCSETD) or hangup.
      
      Wait for the line discipline reference (just like read() or write())
      to retrieve the "current" line discipline id.
      Signed-off-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      b333fc07