1. 27 Sep, 2013 15 commits
    • Tejun Heo's avatar
      rculist: list_first_or_null_rcu() should use list_entry_rcu() · a7179b89
      Tejun Heo authored
      
      
      commit c34ac00caefbe49d40058ae7200bd58725cebb45 upstream.
      
      list_first_or_null() should test whether the list is empty and return
      pointer to the first entry if not in a RCU safe manner.  It's broken
      in several ways.
      
      * It compares __kernel @__ptr with __rcu @__next triggering the
        following sparse warning.
      
        net/core/dev.c:4331:17: error: incompatible types in comparison expression (different address spaces)
      
      * It doesn't perform rcu_dereference*() and computes the entry address
        using container_of() directly from the __rcu pointer which is
        inconsitent with other rculist interface.  As a result, all three
        in-kernel users - net/core/dev.c, macvlan, cgroup - are buggy.  They
        dereference the pointer w/o going through read barrier.
      
      * While ->next dereference passes through list_next_rcu(), the
        compiler is still free to fetch ->next more than once and thus
        nullify the "__ptr != __next" condition check.
      
      Fix it by making list_first_or_null_rcu() dereference ->next directly
      using ACCESS_ONCE() and then use list_entry_rcu() on it like other
      rculist accessors.
      
      v2: Paul pointed out that the compiler may fetch the pointer more than
          once nullifying the condition check.  ACCESS_ONCE() added on
          ->next dereference.
      
      v3: Restored () around macro param which was accidentally removed.
          Spotted by Paul.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reported-by: default avatarFengguang Wu <fengguang.wu@intel.com>
      Cc: Dipankar Sarma <dipankar@in.ibm.com>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Li Zefan <lizefan@huawei.com>
      Cc: Patrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Reviewed-by: default avatarJosh Triplett <josh@joshtriplett.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a7179b89
    • Hans de Goede's avatar
      usb: config->desc.bLength may not exceed amount of data returned by the device · 38a08644
      Hans de Goede authored
      
      
      commit b4f17a488ae2e09bfcf95c0e0b4219c246f1116a upstream.
      
      While reading the config parsing code I noticed this check is missing, without
      this check config->desc.wTotalLength can end up with a value larger then the
      dev->rawdescriptors length for the config, and when userspace then tries to
      get the rawdescriptors bad things may happen.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      38a08644
    • Oliver Neukum's avatar
      USB: cdc-wdm: fix race between interrupt handler and tasklet · e200d6be
      Oliver Neukum authored
      
      
      commit 6dd433e6cf2475ce8abec1b467720858c24450eb upstream.
      
      Both could want to submit the same URB. Some checks of the flag
      intended to prevent that were missing.
      Signed-off-by: default avatarOliver Neukum <oneukum@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e200d6be
    • Daniel Mack's avatar
      usb: ehci-mxc: check for pdata before dereferencing · 0b25f929
      Daniel Mack authored
      commit f375fc520d4df0cd9fcb570f33c103c6c0311f9e upstream.
      
      Commit 7e8d5cd9
      
       ("USB: Add EHCI support for MX27 and MX31 based
      boards") introduced code that could potentially lead to a NULL pointer
      dereference on driver removal.
      
      Fix this by checking for the value of pdata before dereferencing it.
      Signed-off-by: default avatarDaniel Mack <zonque@gmail.com>
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0b25f929
    • Johan Hovold's avatar
      USB: mos7720: fix big-endian control requests · 23595cb6
      Johan Hovold authored
      
      
      commit 3b716caf190ccc6f2a09387210e0e6a26c1d81a4 upstream.
      
      Fix endianess bugs in parallel-port code which caused corrupt
      control-requests to be issued on big-endian machines.
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: default avatarJohan Hovold <jhovold@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      23595cb6
    • Dan Carpenter's avatar
      USB: mos7720: use GFP_ATOMIC under spinlock · 659158c5
      Dan Carpenter authored
      
      
      commit d0bd9a41186e076ea543c397ad8a67a6cf604b55 upstream.
      
      The write_parport_reg_nonblock() function shouldn't sleep because it's
      called with spinlocks held.
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Acked-by: default avatarJohan Hovold <jhovold@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      659158c5
    • Dan Carpenter's avatar
      staging: comedi: dt282x: dt282x_ai_insn_read() always fails · b9ba2a57
      Dan Carpenter authored
      
      
      commit 2c4283ca7cdcc6605859c836fc536fcd83a4525f upstream.
      
      In dt282x_ai_insn_read() we call this macro like:
      wait_for(!mux_busy(), comedi_error(dev, "timeout\n"); return -ETIME;);
      Because the if statement doesn't have curly braces it means we always
      return -ETIME and the function never succeeds.
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Acked-by: default avatarIan Abbott <abbotti@mev.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b9ba2a57
    • Jeff Layton's avatar
      cifs: ensure that srv_mutex is held when dealing with ssocket pointer · b11dc974
      Jeff Layton authored
      commit 73e216a8a42c0ef3d08071705c946c38fdbe12b0 upstream.
      
      Oleksii reported that he had seen an oops similar to this:
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000088
      IP: [<ffffffff814dcc13>] sock_sendmsg+0x93/0xd0
      PGD 0
      Oops: 0000 [#1] PREEMPT SMP
      Modules linked in: ipt_MASQUERADE xt_REDIRECT xt_tcpudp iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip_tables x_tables carl9170 ath usb_storage f2fs nfnetlink_log nfnetlink md4 cifs dns_resolver hid_generic usbhid hid af_packet uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev rfcomm btusb bnep bluetooth qmi_wwan qcserial cdc_wdm usb_wwan usbnet usbserial mii snd_hda_codec_hdmi snd_hda_codec_realtek iwldvm mac80211 coretemp intel_powerclamp kvm_intel kvm iwlwifi snd_hda_intel cfg80211 snd_hda_codec xhci_hcd e1000e ehci_pci snd_hwdep sdhci_pci snd_pcm ehci_hcd microcode psmouse sdhci thinkpad_acpi mmc_core i2c_i801 pcspkr usbcore hwmon snd_timer snd_page_alloc snd ptp rfkill pps_core soundcore evdev usb_common vboxnetflt(O) vboxdrv(O)Oops#2 Part8
       loop tun binfmt_misc fuse msr acpi_call(O) ipv6 autofs4
      CPU: 0 PID: 21612 Comm: kworker/0:1 Tainted: G        W  O 3.10.1SIGN #28
      Hardware name: LENOVO 2306CTO/2306CTO, BIOS G2ET92WW (2.52 ) 02/22/2013
      Workqueue: cifsiod cifs_echo_request [cifs]
      task: ffff8801e1f416f0 ti: ffff880148744000 task.ti: ffff880148744000
      RIP: 0010:[<ffffffff814dcc13>]  [<ffffffff814dcc13>] sock_sendmsg+0x93/0xd0
      RSP: 0000:ffff880148745b00  EFLAGS: 00010246
      RAX: 0000000000000000 RBX: ffff880148745b78 RCX: 0000000000000048
      RDX: ffff880148745c90 RSI: ffff880181864a00 RDI: ffff880148745b78
      RBP: ffff880148745c48 R08: 0000000000000048 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000000 R12: ffff880181864a00
      R13: ffff880148745c90 R14: 0000000000000048 R15: 0000000000000048
      FS:  0000000000000000(0000) GS:ffff88021e200000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000088 CR3: 000000020c42c000 CR4: 00000000001407b0
      Oops#2 Part7
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Stack:
       ffff880148745b30 ffffffff810c4af9 0000004848745b30 ffff880181864a00
       ffffffff81ffbc40 0000000000000000 ffff880148745c90 ffffffff810a5aab
       ffff880148745bc0 ffffffff81ffbc40 ffff880148745b60 ffffffff815a9fb8
      Call Trace:
       [<ffffffff810c4af9>] ? finish_task_switch+0x49/0xe0
       [<ffffffff810a5aab>] ? lock_timer_base.isra.36+0x2b/0x50
       [<ffffffff815a9fb8>] ? _raw_spin_unlock_irqrestore+0x18/0x40
       [<ffffffff810a673f>] ? try_to_del_timer_sync+0x4f/0x70
       [<ffffffff815aa38f>] ? _raw_spin_unlock_bh+0x1f/0x30
       [<ffffffff814dcc87>] kernel_sendmsg+0x37/0x50
       [<ffffffffa081a0e0>] smb_send_kvec+0xd0/0x1d0 [cifs]
       [<ffffffffa081a263>] smb_send_rqst+0x83/0x1f0 [cifs]
       [<ffffffffa081ab6c>] cifs_call_async+0xec/0x1b0 [cifs]
       [<ffffffffa08245e0>] ? free_rsp_buf+0x40/0x40 [cifs]
      Oops#2 Part6
       [<ffffffffa082606e>] SMB2_echo+0x8e/0xb0 [cifs]
       [<ffffffffa0808789>] cifs_echo_request+0x79/0xa0 [cifs]
       [<ffffffff810b45b3>] process_one_work+0x173/0x4a0
       [<ffffffff810b52a1>] worker_thread+0x121/0x3a0
       [<ffffffff810b5180>] ? manage_workers.isra.27+0x2b0/0x2b0
       [<ffffffff810bae00>] kthread+0xc0/0xd0
       [<ffffffff810bad40>] ? kthread_create_on_node+0x120/0x120
       [<ffffffff815b199c>] ret_from_fork+0x7c/0xb0
       [<ffffffff810bad40>] ? kthread_create_on_node+0x120/0x120
      Code: 84 24 b8 00 00 00 4c 89 f1 4c 89 ea 4c 89 e6 48 89 df 4c 89 60 18 48 c7 40 28 00 00 00 00 4c 89 68 30 44 89 70 14 49 8b 44 24 28 <ff> 90 88 00 00 00 3d ef fd ff ff 74 10 48 8d 65 e0 5b 41 5c 41
       RIP  [<ffffffff814dcc13>] sock_sendmsg+0x93/0xd0
       RSP <ffff880148745b00>
      CR2: 0000000000000088
      
      The client was in the middle of trying to send a frame when the
      server->ssocket pointer got zeroed out. In most places, that we access
      that pointer, the srv_mutex is held. There's only one spot that I see
      that the server->ssocket pointer gets set and the srv_mutex isn't held.
      This patch corrects that.
      
      The upstream bug report was here:
      
          https://bugzilla.kernel.org/show_bug.cgi?id=60557
      
      Reported-by: default avatarOleksii Shevchuk <alxchk@gmail.com>
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b11dc974
    • Shawn Nematbakhsh's avatar
      usb: xhci: Disable runtime PM suspend for quirky controllers · 8d1c1a31
      Shawn Nematbakhsh authored
      commit c8476fb855434c733099079063990e5bfa7ecad6 upstream.
      
      If a USB controller with XHCI_RESET_ON_RESUME goes to runtime suspend,
      a reset will be performed upon runtime resume. Any previously suspended
      devices attached to the controller will be re-enumerated at this time.
      This will cause problems, for example, if an open system call on the
      device triggered the resume (the open call will fail).
      
      Note that this change is only relevant when persist_enabled is not set
      for USB devices.
      
      This patch should be backported to kernels as old as 3.0, that
      contain the commit c877b3b2
      
       "xhci: Add
      reset on resume quirk for asrock p67 host".
      Signed-off-by: default avatarShawn Nematbakhsh <shawnn@chromium.org>
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8d1c1a31
    • Sarah Sharp's avatar
      xhci-plat: Don't enable legacy PCI interrupts. · df5831d2
      Sarah Sharp authored
      
      
      commit 52fb61250a7a132b0cfb9f4a1060a1f3c49e5a25 upstream.
      
      The xHCI platform driver calls into usb_add_hcd to register the irq for
      its platform device.  It does not want the xHCI generic driver to
      register an interrupt for it at all.  The original code did that by
      setting the XHCI_BROKEN_MSI quirk, which tells the xHCI driver to not
      enable MSI or MSI-X for a PCI host.
      
      Unfortunately, if CONFIG_PCI is enabled, and CONFIG_USB_DW3 is enabled,
      the xHCI generic driver will attempt to register a legacy PCI interrupt
      for the xHCI platform device in xhci_try_enable_msi().  This will result
      in a bogus irq being registered, since the underlying device is a
      platform_device, not a pci_device, and thus the pci_device->irq pointer
      will be bogus.
      
      Add a new quirk, XHCI_PLAT, so that the xHCI generic driver can
      distinguish between a PCI device that can't handle MSI or MSI-X, and a
      platform device that should not have its interrupts touched at all.
      This quirk may be useful in the future, in case other corner cases like
      this arise.
      
      This patch should be backported to kernels as old as 3.9, that
      contain the commit 00eed9c814cb8f281be6f0f5d8f45025dc0a97eb "USB: xhci:
      correctly enable interrupts".
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Reported-by: default avatarYu Y Wang <yu.y.wang@intel.com>
      Tested-by: default avatarYu Y Wang <yu.y.wang@intel.com>
      Reviewed-by: default avatarFelipe Balbi <balbi@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      df5831d2
    • Peter Maydell's avatar
      ARM: PCI: versatile: Fix SMAP register offsets · 5aea7495
      Peter Maydell authored
      
      
      commit 99f2b130370b904ca5300079243fdbcafa2c708b upstream.
      
      The SMAP register offsets in the versatile PCI controller code were
      all off by four.  (This didn't have any observable bad effects
      because on this board PHYS_OFFSET is zero, and (a) writing zero to
      the flags register at offset 0x10 has no effect and (b) the reset
      value of the SMAP register is zero anyway, so failing to write SMAP2
      didn't matter.)
      Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarKevin Hilman <khilman@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5aea7495
    • Roger Pau Monne's avatar
      xen-gnt: prevent adding duplicate gnt callbacks · 9fd23802
      Roger Pau Monne authored
      
      
      commit 5f338d9001094a56cf87bd8a280b4e7ff953bb59 upstream.
      
      With the current implementation, the callback in the tail of the list
      can be added twice, because the check done in
      gnttab_request_free_callback is bogus, callback->next can be NULL if
      it is the last callback in the list. If we add the same callback twice
      we end up with an infinite loop, were callback == callback->next.
      
      Replace this check with a proper one that iterates over the list to
      see if the callback has already been added.
      Signed-off-by: default avatarRoger Pau Monné <roger.pau@citrix.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Acked-by: default avatarMatt Wilson <msw@amazon.com>
      Reviewed-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9fd23802
    • Anton Blanchard's avatar
      powerpc: Handle unaligned ldbrx/stdbrx · 774620ba
      Anton Blanchard authored
      
      
      commit 230aef7a6a23b6166bd4003bfff5af23c9bd381f upstream.
      
      Normally when we haven't implemented an alignment handler for
      a load or store instruction the process will be terminated.
      
      The alignment handler uses the DSISR (or a pseudo one) to locate
      the right handler. Unfortunately ldbrx and stdbrx overlap lfs and
      stfs so we incorrectly think ldbrx is an lfs and stdbrx is an
      stfs.
      
      This bug is particularly nasty - instead of terminating the
      process we apply an incorrect fixup and continue on.
      
      With more and more overlapping instructions we should stop
      creating a pseudo DSISR and index using the instruction directly,
      but for now add a special case to catch ldbrx/stdbrx.
      Signed-off-by: default avatarAnton Blanchard <anton@samba.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      774620ba
    • Herbert Xu's avatar
      crypto: api - Fix race condition in larval lookup · d2fb5fcd
      Herbert Xu authored
      
      
      commit 77dbd7a95e4a4f15264c333a9e9ab97ee27dc2aa upstream.
      
      crypto_larval_lookup should only return a larval if it created one.
      Any larval created by another entity must be processed through
      crypto_larval_wait before being returned.
      
      Otherwise this will lead to a larval being killed twice, which
      will most likely lead to a crash.
      Reported-by: default avatarKees Cook <keescook@chromium.org>
      Tested-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d2fb5fcd
    • Alan Stern's avatar
      SCSI: sd: Fix potential out-of-bounds access · 8283dfa4
      Alan Stern authored
      
      
      commit 984f1733fcee3fbc78d47e26c5096921c5d9946a upstream.
      
      This patch fixes an out-of-bounds error in sd_read_cache_type(), found
      by Google's AddressSanitizer tool.  When the loop ends, we know that
      "offset" lies beyond the end of the data in the buffer, so no Caching
      mode page was found.  In theory it may be present, but the buffer size
      is limited to 512 bytes.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8283dfa4
  2. 14 Sep, 2013 24 commits
  3. 08 Sep, 2013 1 commit