1. 27 Apr, 2014 7 commits
    • Claudio Takahasi's avatar
      Bluetooth: Fix removing Long Term Key · 2dbecc73
      Claudio Takahasi authored
      commit 5981a882 upstream.
      
      This patch fixes authentication failure on LE link re-connection when
      BlueZ acts as slave (peripheral). LTK is removed from the internal list
      after its first use causing PIN or Key missing reply when re-connecting
      the link. The LE Long Term Key Request event indicates that the master
      is attempting to encrypt or re-encrypt the link.
      
      Pre-condition: BlueZ host paired and running as slave.
      How to reproduce(master):
      
        1) Establish an ACL LE encrypted link
        2) Disconnect the link
        3) Try to re-establish the ACL LE encrypted link (fails)
      
      > HCI Event: LE Meta Event (0x3e) plen 19
            LE Connection Complete (0x01)
              Status: Success (0x00)
              Handle: 64
              Role: Slave (0x01)
      ...
      @ Device Connected: 00:02:72:DC:29:C9 (1) flags 0x0000
      > HCI Event: LE Meta Event (0x3e) plen 13
            LE Long Term Key Request (0x05)
              Handle: 64
              Random number: 875be18439d9aa37
              Encryption diversifier: 0x76ed
      < HCI Command: LE Long Term Key Request Reply (0x08|0x001a) plen 18
              Handle: 64
              Long term key: 2aa531db2fce9f00a0569c7d23d17409
      > HCI Event: Command Complete (0x0e) plen 6
            LE Long Term Key Request Reply (0x08|0x001a) ncmd 1
              Status: Success (0x00)
              Handle: 64
      > HCI Event: Encryption Change (0x08) plen 4
              Status: Success (0x00)
              Handle: 64
              Encryption: Enabled with AES-CCM (0x01)
      ...
      @ Device Disconnected: 00:02:72:DC:29:C9 (1) reason 3
      < HCI Command: LE Set Advertise Enable (0x08|0x000a) plen 1
              Advertising: Enabled (0x01)
      > HCI Event: Command Complete (0x0e) plen 4
            LE Set Advertise Enable (0x08|0x000a) ncmd 1
              Status: Success (0x00)
      > HCI Event: LE Meta Event (0x3e) plen 19
            LE Connection Complete (0x01)
              Status: Success (0x00)
              Handle: 64
              Role: Slave (0x01)
      ...
      @ Device Connected: 00:02:72:DC:29:C9 (1) flags 0x0000
      > HCI Event: LE Meta Event (0x3e) plen 13
            LE Long Term Key Request (0x05)
              Handle: 64
              Random number: 875be18439d9aa37
              Encryption diversifier: 0x76ed
      < HCI Command: LE Long Term Key Request Neg Reply (0x08|0x001b) plen 2
              Handle: 64
      > HCI Event: Command Complete (0x0e) plen 6
            LE Long Term Key Request Neg Reply (0x08|0x001b) ncmd 1
              Status: Success (0x00)
              Handle: 64
      > HCI Event: Disconnect Complete (0x05) plen 4
              Status: Success (0x00)
              Handle: 64
              Reason: Authentication Failure (0x05)
      @ Device Disconnected: 00:02:72:DC:29:C9 (1) reason 0
      Signed-off-by: default avatarClaudio Takahasi <claudio.takahasi@openbossa.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2dbecc73
    • Oleg Nesterov's avatar
      pid_namespace: pidns_get() should check task_active_pid_ns() != NULL · a15c36b2
      Oleg Nesterov authored
      commit d2308225 upstream.
      
      pidns_get()->get_pid_ns() can hit ns == NULL. This task_struct can't
      go away, but task_active_pid_ns(task) is NULL if release_task(task)
      was already called. Alternatively we could change get_pid_ns(ns) to
      check ns != NULL, but it seems that other callers are fine.
      Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
      Cc: Eric W. Biederman ebiederm@xmission.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a15c36b2
    • Hannes Reinecke's avatar
      tty: Set correct tty name in 'active' sysfs attribute · f5b4cbf5
      Hannes Reinecke authored
      commit 723abd87 upstream.
      
      The 'active' sysfs attribute should refer to the currently active tty
      devices the console is running on, not the currently active console. The
      console structure doesn't refer to any device in sysfs, only the tty the
      console is running on has. So we need to print out the tty names in
      'active', not the console names.
      
      There is one special-case, which is tty0. If the console is directed to
      it, we want 'tty0' to show up in the file, so user-space knows that the
      messages get forwarded to the active VT. The ->device() callback would
      resolve tty0, though. Hence, treat it special and don't call into the VT
      layer to resolve it (plymouth is known to depend on it).
      
      Cc: Lennart Poettering <lennart@poettering.net>
      Cc: Kay Sievers <kay@vrfy.org>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Signed-off-by: default avatarWerner Fink <werner@suse.de>
      Signed-off-by: default avatarHannes Reinecke <hare@suse.de>
      Signed-off-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f5b4cbf5
    • Ian Abbott's avatar
      staging: comedi: 8255_pci: initialize MITE data window · 7a63f583
      Ian Abbott authored
      commit 268d1e79 upstream.
      
      According to National Instruments' PCI-DIO-96/PXI-6508/PCI-6503 User
      Manual, the physical address in PCI BAR1 needs to be OR'ed with 0x80 and
      written to register offset 0xC0 in the "MITE" registers (BAR0).  Do so
      during initialization of the National Instruments boards handled by the
      "8255_pci" driver.  The boards were previously handled by the
      "ni_pcidio" driver, where the initialization was done by `mite_setup()`
      in the "mite" module.  The "mite" module comes with too much extra
      baggage for the "8255_pci" driver to deal with so use a local, simpler
      initialization function.
      Signed-off-by: default avatarIan Abbott <abbotti@mev.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7a63f583
    • Neil Horman's avatar
      x86: Adjust irq remapping quirk for older revisions of 5500/5520 chipsets · d7a834fb
      Neil Horman authored
      commit 6f8a1b33 upstream.
      
      Commit 03bbcb2e (iommu/vt-d: add quirk for broken interrupt
      remapping on 55XX chipsets) properly disables irq remapping on the
      5500/5520 chipsets that don't correctly perform that feature.
      
      However, when I wrote it, I followed the errata sheet linked in that
      commit too closely, and explicitly tied the activation of the quirk to
      revision 0x13 of the chip, under the assumption that earlier revisions
      were not in the field.  Recently a system was reported to be suffering
      from this remap bug and the quirk hadn't triggered, because the
      revision id register read at a lower value that 0x13, so the quirk
      test failed improperly.  Given this, it seems only prudent to adjust
      this quirk so that any revision less than 0x13 has the quirk asserted.
      
      [ tglx: Removed the 0x12 comparison of pci id 3405 as this is covered
          	by the <= 0x13 check already ]
      Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: x86@kernel.org
      Link: http://lkml.kernel.org/r/1394649873-14913-1-git-send-email-nhorman@tuxdriver.comSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d7a834fb
    • Jiri Slaby's avatar
      Char: ipmi_bt_sm, fix infinite loop · 96a405de
      Jiri Slaby authored
      commit a94cdd1f upstream.
      
      In read_all_bytes, we do
      
        unsigned char i;
        ...
        bt->read_data[0] = BMC2HOST;
        bt->read_count = bt->read_data[0];
        ...
        for (i = 1; i <= bt->read_count; i++)
          bt->read_data[i] = BMC2HOST;
      
      If bt->read_data[0] == bt->read_count == 255, we loop infinitely in the
      'for' loop.  Make 'i' an 'int' instead of 'char' to get rid of the
      overflow and finish the loop after 255 iterations every time.
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Reported-and-debugged-by: default avatarRui Hui Dian <rhdian@novell.com>
      Cc: Tomas Cech <tcech@suse.cz>
      Cc: Corey Minyard <minyard@acm.org>
      Cc: <openipmi-developer@lists.sourceforge.net>
      Signed-off-by: default avatarCorey Minyard <cminyard@mvista.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      96a405de
    • Mikulas Patocka's avatar
      user namespace: fix incorrect memory barriers · 98afe6df
      Mikulas Patocka authored
      commit e79323bd upstream.
      
      smp_read_barrier_depends() can be used if there is data dependency between
      the readers - i.e. if the read operation after the barrier uses address
      that was obtained from the read operation before the barrier.
      
      In this file, there is only control dependency, no data dependecy, so the
      use of smp_read_barrier_depends() is incorrect. The code could fail in the
      following way:
      * the cpu predicts that idx < entries is true and starts executing the
        body of the for loop
      * the cpu fetches map->extent[0].first and map->extent[0].count
      * the cpu fetches map->nr_extents
      * the cpu verifies that idx < extents is true, so it commits the
        instructions in the body of the for loop
      
      The problem is that in this scenario, the cpu read map->extent[0].first
      and map->nr_extents in the wrong order. We need a full read memory barrier
      to prevent it.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      98afe6df
  2. 14 Apr, 2014 33 commits