Linux 3.0.97

commit 3c7f3084a5583637e668a80457b18f90a8743f0d
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Sep 26 16:53:10 2013 -0700

    Linux 3.0.97

commit 59e272211a96b1a4aee7ca1c328353f6c9b7e92e
Author: Anand Avati <avati@redhat.com>
Date:   Tue Aug 20 02:21:07 2013 -0400

    fuse: invalidate inode attributes on xattr modification

    commit d331a415aef98717393dda0be69b7947da08eba3 upstream.

    Calls like setxattr and removexattr result in updation of ctime.
    Therefore invalidate inode attributes to force a refresh.

    Signed-off-by: Anand Avati <avati@redhat.com>
    Reviewed-by: Brian Foster <bfoster@redhat.com>
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f35b12e6453f12bb65f7d492b751f05cdeb41518
Author: Maxim Patlasov <MPatlasov@parallels.com>
Date:   Mon Aug 12 20:39:30 2013 +0400

    fuse: postpone end_page_writeback() in fuse_writepage_locked()

    commit 4a4ac4eba1010ef9a804569058ab29e3450c0315 upstream.

    The patch fixes a race between ftruncate(2), mmap-ed write and write(2):

    1) An user makes a page dirty via mmap-ed write.
    2) The user performs shrinking truncate(2) intended to purge the page.
    3) Before fuse_do_setattr calls truncate_pagecache, the page goes to
       writeback. fuse_writepage_locked fills FUSE_WRITE request and releases
       the original page by end_page_writeback.
    4) fuse_do_setattr() completes and successfully returns. Since now, i_mutex
       is free.
    5) Ordinary write(2) extends i_size back to cover the page. Note that
       fuse_send_write_pages do wait for fuse writeback, but for another
       page->index.
    6) fuse_writepage_locked proceeds by queueing FUSE_WRITE request.
       fuse_send_writepage is supposed to crop inarg->size of the request,
       but it doesn't because i_size has already been extended back.

    Moving end_page_writeback to the end of fuse_writepage_locked fixes the
    race because now the fact that truncate_pagecache is successfully returned
    infers that fuse_writepage_locked has already called end_page_writeback.
    And this, in turn, infers that fuse_flush_writepages has already called
    fuse_send_writepage, and the latter used valid (shrunk) i_size. write(2)
    could not extend it because of i_mutex held by ftruncate(2).

    Signed-off-by: Maxim Patlasov <mpatlasov@parallels.com>
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cd76cc4459ac83aa17226ceac9058abbfe8385c8
Author: Jan Kara <jack@suse.cz>
Date:   Thu Jul 25 11:49:11 2013 +0200

    isofs: Refuse RW mount of the filesystem instead of making it RO

    commit 17b7f7cf58926844e1dd40f5eb5348d481deca6a upstream.

    Refuse RW mount of isofs filesystem. So far we just silently changed it
    to RO mount but when the media is writeable, block layer won't notice
    this change and thus will think device is used RW and will block eject
    button of the drive. That is unexpected by users because for
    non-writeable media eject button works just fine.

    Userspace mount(8) command handles this just fine and retries mounting
    with MS_RDONLY set so userspace shouldn't see any regression.  Plus any
    tool mounting isofs is likely confronted with the case of read-only
    media where block layer already refuses to mount the filesystem without
    MS_RDONLY set so our behavior shouldn't be anything new for it.

    Reported-by: Hui Wang <hui.wang@canonical.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 85a39b77027438bec7f1a1ebbbc46925d22f7b5c
Author: Libin <huawei.libin@huawei.com>
Date:   Wed Sep 11 14:20:38 2013 -0700

    mm/huge_memory.c: fix potential NULL pointer dereference

    commit a8f531ebc33052642b4bd7b812eedf397108ce64 upstream.

    In collapse_huge_page() there is a race window between releasing the
    mmap_sem read lock and taking the mmap_sem write lock, so find_vma() may
    return NULL.  So check the return value to avoid NULL pointer dereference.

    collapse_huge_page
        khugepaged_alloc_page
            up_read(&mm->mmap_sem)
        down_write(&mm->mmap_sem)
        vma = find_vma(mm, address)

    Signed-off-by: Libin <huawei.libin@huawei.com>
    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Reviewed-by: Wanpeng Li <liwanp@linux.vnet.ibm.com>
    Reviewed-by: Michal Hocko <mhocko@suse.cz>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 49fa5f65bff58a34362e3a29733cbec7a866871d
Author: Greg Thelen <gthelen@google.com>
Date:   Wed Sep 11 14:23:08 2013 -0700

    memcg: fix multiple large threshold notifications

    commit 2bff24a3707093c435ab3241c47dcdb5f16e432b upstream.

    A memory cgroup with (1) multiple threshold notifications and (2) at least
    one threshold >=2G was not reliable.  Specifically the notifications would
    either not fire or would not fire in the proper order.

    The __mem_cgroup_threshold() signaling logic depends on keeping 64 bit
    thresholds in sorted order.  mem_cgroup_usage_register_event() sorts them
    with compare_thresholds(), which returns the difference of two 64 bit
    thresholds as an int.  If the difference is positive but has bit[31] set,
    then sort() treats the difference as negative and breaks sort order.

    This fix compares the two arbitrary 64 bit thresholds returning the
    classic -1, 0, 1 result.

    The test below sets two notifications (at 0x1000 and 0x81001000):
      cd /sys/fs/cgroup/memory
      mkdir x
      for x in 4096 2164264960; do
        cgroup_event_listener x/memory.usage_in_bytes $x | sed "s/^/$x listener:/" &
      done
      echo $$ > x/cgroup.procs
      anon_leaker 500M

    v3.11-rc7 fails to signal the 4096 event listener:
      Leaking...
      Done leaking pages.

    Patched v3.11-rc7 properly notifies:
      Leaking...
      4096 listener:2013:8:31:14:13:36
      Done leaking pages.

    The fixed bug is old.  It appears to date back to the introduction of
    memcg threshold notifications in v2.6.34-rc1-116-g2e72b6347c94 "memcg:
    implement memory thresholds"

    Signed-off-by: Greg Thelen <gthelen@google.com>
    Acked-by: Michal Hocko <mhocko@suse.cz>
    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6becb5ec6dbf34850e39fd97860206c1628ccb94
Author: Jie Liu <jeff.liu@oracle.com>
Date:   Wed Sep 11 14:20:05 2013 -0700

    ocfs2: fix the end cluster offset of FIEMAP

    commit 28e8be31803b19d0d8f76216cb11b480b8a98bec upstream.

    Call fiemap ioctl(2) with given start offset as well as an desired mapping
    range should show extents if possible.  However, we somehow figure out the
    end offset of mapping via 'mapping_end -= cpos' before iterating the
    extent records which would cause problems if the given fiemap length is
    too small to a cluster size, e.g,

    Cluster size 4096:
    debugfs.ocfs2 1.6.3
            Block Size Bits: 12   Cluster Size Bits: 12

    The extended fiemap test utility From David:
    https://gist.github.com/anonymous/6172331

    # dd if=/dev/urandom of=/ocfs2/test_file bs=1M count=1000
    # ./fiemap /ocfs2/test_file 4096 10
    start: 4096, length: 10
    File /ocfs2/test_file has 0 extents:
    #   Logical          Physical         Length           Flags
        ^^^^^ <-- No extent is shown

    In this case, at ocfs2_fiemap(): cpos == mapping_end == 1. Hence the
    loop of searching extent records was not executed at all.

    This patch remove the in question 'mapping_end -= cpos', and loops
    until the cpos is larger than the mapping_end as usual.

    # ./fiemap /ocfs2/test_file 4096 10
    start: 4096, length: 10
    File /ocfs2/test_file has 1 extents:
    #   Logical          Physical         Length           Flags
    0:  0000000000000000 0000000056a01000 0000000006a00000 0000

    Signed-off-by: Jie Liu <jeff.liu@oracle.com>
    Reported-by: David Weber <wb@munzinger.de>
    Tested-by: David Weber <wb@munzinger.de>
    Cc: Sunil Mushran <sunil.mushran@gmail.com>
    Cc: Mark Fashen <mfasheh@suse.de>
    Cc: Joel Becker <jlbec@evilplan.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fc4a8fd8746dcd6ff011bc61c06fe9cf5ed2015a
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Aug 28 22:32:01 2013 +0200

    HID: check for NULL field when setting values

    commit be67b68d52fa28b9b721c47bb42068f0c1214855 upstream.

    Defensively check that the field to be worked on is not NULL.

    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0d564bb5984ae5b94233bc0bdb0e38073fc1b038
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Aug 28 22:31:28 2013 +0200

    HID: ntrig: validate feature report details

    commit 875b4e3763dbc941f15143dd1a18d10bb0be303b upstream.

    A HID device could send a malicious feature report that would cause the
    ntrig HID driver to trigger a NULL dereference during initialization:

    [57383.031190] usb 3-1: New USB device found, idVendor=1b96, idProduct=0001
    ...
    [57383.315193] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
    [57383.315308] IP: [<ffffffffa08102de>] ntrig_probe+0x25e/0x420 [hid_ntrig]

    CVE-2013-2896

    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Rafi Rubin <rafi@seas.upenn.edu>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 645c9dcabb2c234e6d4a546125830d04988a1f90
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Aug 28 22:29:55 2013 +0200

    HID: validate HID report id size

    commit 43622021d2e2b82ea03d883926605bdd0525e1d1 upstream.

    The "Report ID" field of a HID report is used to build indexes of
    reports. The kernel's index of these is limited to 256 entries, so any
    malicious device that sets a Report ID greater than 255 will trigger
    memory corruption on the host:

    [ 1347.156239] BUG: unable to handle kernel paging request at ffff88094958a878
    [ 1347.156261] IP: [<ffffffff813e4da0>] hid_register_report+0x2a/0x8b

    CVE-2013-2888

    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c993386d8c99c60ffb1161076040f3ffb46c0794
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Aug 28 22:30:49 2013 +0200

    HID: pantherlord: validate output report details

    commit 412f30105ec6735224535791eed5cdc02888ecb4 upstream.

    A HID device could send a malicious output report that would cause the
    pantherlord HID driver to write beyond the output report allocation
    during initialization, causing a heap overflow:

    [  310.939483] usb 1-1: New USB device found, idVendor=0e8f, idProduct=0003
    ...
    [  315.980774] BUG kmalloc-192 (Tainted: G        W   ): Redzone overwritten

    CVE-2013-2892

    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8600be1d3927e177b80c7ee9263ef3b28a0ba115
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Tue Aug 13 12:33:28 2013 +0200

    ath9k: avoid accessing MRC registers on single-chain devices

    commit a1c781bb20ac1e03280e420abd47a99eb8bbdd3b upstream.

    They are not implemented, and accessing them might trigger errors

    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit be84480edb2b552c2fb9ca940c6bb07464306108
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Tue Aug 6 14:18:10 2013 +0200

    ath9k: always clear ps filter bit on new assoc

    commit 026d5b07c03458f9c0ccd19c3850564a5409c325 upstream.

    Otherwise in some cases, EAPOL frames might be filtered during the
    initial handshake, causing delays and assoc failures.

    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bea7e186543344d62c3a2f04032f494a59c8fc6e
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Sep 9 10:20:48 2013 +0200

    ALSA: hda - Add Toshiba Satellite C870 to MSI blacklist

    commit 83f72151352791836a1b9c1542614cc9bf71ac61 upstream.

    Toshiba Satellite C870 shows interrupt problems occasionally when
    certain mixer controls like "Mic Switch" is toggled.  This seems
    worked around by not using MSI.

    Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=833585
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ee7ad6684665dfe84977c4cfb076c4b7b73a68fc
Author: Mike Dyer <mike.dyer@md-soft.co.uk>
Date:   Fri Aug 16 18:36:28 2013 +0100

    ASoC: wm8960: Fix PLL register writes

    commit 85fa532b6ef920b32598df86b194571a7059a77c upstream.

    Bit 9 of PLL2,3 and 4 is reserved as '0'. The 24bit fractional part
    should be split across each register in 8bit chunks.

    Signed-off-by: Mike Dyer <mike.dyer@md-soft.co.uk>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c97081c634fdee51845ca8a30f394cf06125a509
Author: Tejun Heo <tj@kernel.org>
Date:   Fri Jun 28 10:34:48 2013 -0700

    rculist: list_first_or_null_rcu() should use list_entry_rcu()

    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: Tejun Heo <tj@kernel.org>
    Reported-by: Fengguang 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: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Reviewed-by: Josh Triplett <josh@joshtriplett.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ff819a0c7f12179d197aa06841087964dd2be7d3
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sat Aug 3 16:37:48 2013 +0200

    usb: config->desc.bLength may not exceed amount of data returned by the device

    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: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe3efa501f32fc05483a095334573799a954d1ab
Author: Oliver Neukum <oneukum@suse.de>
Date:   Tue Aug 6 14:22:59 2013 +0200

    USB: cdc-wdm: fix race between interrupt handler and tasklet

    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: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5f8ce0764bb3d54090856cca1c8562c0435003ca
Author: Johan Hovold <jhovold@gmail.com>
Date:   Mon Aug 19 13:05:45 2013 +0200

    USB: mos7720: fix big-endian control requests

    commit 3b716caf190ccc6f2a09387210e0e6a26c1d81a4 upstream.

    Fix endianess bugs in parallel-port code which caused corrupt
    control-requests to be issued on big-endian machines.

    Reported-by: kbuild test robot <fengguang.wu@intel.com>
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d723c89020d4f5f54b42997ae5e90f13bc620d8b
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Aug 16 10:16:59 2013 +0300

    USB: mos7720: use GFP_ATOMIC under spinlock

    commit d0bd9a41186e076ea543c397ad8a67a6cf604b55 upstream.

    The write_parport_reg_nonblock() function shouldn't sleep because it's
    called with spinlocks held.

    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 71d5f63763f01e5577c465d6752b7060ba105fa6
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Aug 20 11:57:35 2013 +0300

    staging: comedi: dt282x: dt282x_ai_insn_read() always fails

    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: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Ian Abbott <abbotti@mev.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 186ad2276339b0fc63f06146627b6d15c5058c4f
Author: Jeff Layton <jlayton@redhat.com>
Date:   Thu Sep 5 08:38:10 2013 -0400

    cifs: ensure that srv_mutex is held when dealing with ssocket pointer

    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: Oleksii Shevchuk <alxchk@gmail.com>
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <smfrench@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3fa24717e9b3e4d50f5dd912270613d5887f361c
Author: Shawn Nematbakhsh <shawnn@chromium.org>
Date:   Mon Aug 19 10:36:13 2013 -0700

    usb: xhci: Disable runtime PM suspend for quirky controllers

    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 c877b3b2ad5cb9d4fe523c5496185cc328ff3ae9 "xhci: Add
    reset on resume quirk for asrock p67 host".

    Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4595b6def019ab1324b3948dfbaa959963a132e8
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Thu Aug 22 17:47:50 2013 +0100

    ARM: PCI: versatile: Fix SMAP register offsets

    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: Peter Maydell <peter.maydell@linaro.org>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Kevin Hilman <khilman@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit def5a30f1a9766eb269234971f45736d67326925
Author: Roger Pau Monne <roger.pau@citrix.com>
Date:   Wed Jul 31 17:00:42 2013 +0200

    xen-gnt: prevent adding duplicate gnt callbacks

    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: Roger Pau Monné <roger.pau@citrix.com>
    Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Cc: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Acked-by: Matt Wilson <msw@amazon.com>
    Reviewed-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7b900d1daf22341794f5fd7a0ec1fe97966b8590
Author: Anton Blanchard <anton@samba.org>
Date:   Wed Aug 7 02:01:19 2013 +1000

    powerpc: Handle unaligned ldbrx/stdbrx

    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: Anton Blanchard <anton@samba.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 162c7c77893520b95698d6a7d146295aab1397c2
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Sun Sep 8 14:33:50 2013 +1000

    crypto: api - Fix race condition in larval lookup

    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: Kees Cook <keescook@chromium.org>
    Tested-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 173798ef2abbec8faf2a4397a24bd357fecfe008
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Fri Sep 6 11:49:51 2013 -0400

    SCSI: sd: Fix potential out-of-bounds access

    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: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>