commit 234d96ee0f3b8e49501d068a2a3165aa4db60903
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Nov 20 10:43:41 2013 -0800

    Linux 3.4.70

commit a73ff6145f62f0e744aeb095bf7119edfcb8a2e7
Author: Krzysztof Mazur <krzysiek@podlesie.net>
Date:   Thu Aug 22 14:49:38 2013 +0200

    usb: fix cleanup after failure in hub_configure()
    
    commit d0308d4b6b02597f39fc31a9bddf7bb3faad5622 upstream.
    
    If the hub_configure() fails after setting the hdev->maxchild
    the hub->ports might be NULL or point to uninitialized kzallocated
    memory causing NULL pointer dereference in hub_quiesce() during cleanup.
    
    Now after such error the hdev->maxchild is set to 0 to avoid cleanup
    of uninitialized ports.
    
    Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 17447567e81dd2e9614ec4837128daebc0c4abb1
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Mon Feb 4 15:56:05 2013 +0400

    PCI/PM: Clear state_saved during suspend
    
    commit 82fee4d67ab86d6fe5eb0f9a9e988ca9d654d765 upstream.
    
    This patch clears pci_dev->state_saved at the beginning of suspending.
    PCI config state may be saved long before that.  Some drivers call
    pci_save_state() from the ->probe() callback to get snapshot of sane
    configuration space to use in the ->slot_reset() callback.
    
    [wangyj: adjust context]
    Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org> # add comment
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d1814ea12da067fda7bac933e06ef205163617f6
Author: Nicolas Pitre <nicolas.pitre@linaro.org>
Date:   Tue Mar 12 13:00:42 2013 +0100

    ARM: 7670/1: fix the memset fix
    
    commit 418df63adac56841ef6b0f1fcf435bc64d4ed177 upstream.
    
    Commit 455bd4c430b0 ("ARM: 7668/1: fix memset-related crashes caused by
    recent GCC (4.7.2) optimizations") attempted to fix a compliance issue
    with the memset return value.  However the memset itself became broken
    by that patch for misaligned pointers.
    
    This fixes the above by branching over the entry code from the
    misaligned fixup code to avoid reloading the original pointer.
    
    Also, because the function entry alignment is wrong in the Thumb mode
    compilation, that fixup code is moved to the end.
    
    While at it, the entry instructions are slightly reworked to help dual
    issue pipelines.
    
    Signed-off-by: Nicolas Pitre <nico@linaro.org>
    Tested-by: Alexander Holler <holler@ahsoftware.de>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Cc: Eric Bénard <eric@eukrea.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e6fffec6636ffa3062891bae69a3895bbb73b148
Author: Ivan Djelic <ivan.djelic@parrot.com>
Date:   Wed Mar 6 20:09:27 2013 +0100

    ARM: 7668/1: fix memset-related crashes caused by recent GCC (4.7.2) optimizations
    
    commit 455bd4c430b0c0a361f38e8658a0d6cb469942b5 upstream.
    
    Recent GCC versions (e.g. GCC-4.7.2) perform optimizations based on
    assumptions about the implementation of memset and similar functions.
    The current ARM optimized memset code does not return the value of
    its first argument, as is usually expected from standard implementations.
    
    For instance in the following function:
    
    void debug_mutex_lock_common(struct mutex *lock, struct mutex_waiter *waiter)
    {
    	memset(waiter, MUTEX_DEBUG_INIT, sizeof(*waiter));
    	waiter->magic = waiter;
    	INIT_LIST_HEAD(&waiter->list);
    }
    
    compiled as:
    
    800554d0 <debug_mutex_lock_common>:
    800554d0:       e92d4008        push    {r3, lr}
    800554d4:       e1a00001        mov     r0, r1
    800554d8:       e3a02010        mov     r2, #16 ; 0x10
    800554dc:       e3a01011        mov     r1, #17 ; 0x11
    800554e0:       eb04426e        bl      80165ea0 <memset>
    800554e4:       e1a03000        mov     r3, r0
    800554e8:       e583000c        str     r0, [r3, #12]
    800554ec:       e5830000        str     r0, [r3]
    800554f0:       e5830004        str     r0, [r3, #4]
    800554f4:       e8bd8008        pop     {r3, pc}
    
    GCC assumes memset returns the value of pointer 'waiter' in register r0; causing
    register/memory corruptions.
    
    This patch fixes the return value of the assembly version of memset.
    It adds a 'mov' instruction and merges an additional load+store into
    existing load/store instructions.
    For ease of review, here is a breakdown of the patch into 4 simple steps:
    
    Step 1
    ======
    Perform the following substitutions:
    ip -> r8, then
    r0 -> ip,
    and insert 'mov ip, r0' as the first statement of the function.
    At this point, we have a memset() implementation returning the proper result,
    but corrupting r8 on some paths (the ones that were using ip).
    
    Step 2
    ======
    Make sure r8 is saved and restored when (! CALGN(1)+0) == 1:
    
    save r8:
    -       str     lr, [sp, #-4]!
    +       stmfd   sp!, {r8, lr}
    
    and restore r8 on both exit paths:
    -       ldmeqfd sp!, {pc}               @ Now <64 bytes to go.
    +       ldmeqfd sp!, {r8, pc}           @ Now <64 bytes to go.
    (...)
            tst     r2, #16
            stmneia ip!, {r1, r3, r8, lr}
    -       ldr     lr, [sp], #4
    +       ldmfd   sp!, {r8, lr}
    
    Step 3
    ======
    Make sure r8 is saved and restored when (! CALGN(1)+0) == 0:
    
    save r8:
    -       stmfd   sp!, {r4-r7, lr}
    +       stmfd   sp!, {r4-r8, lr}
    
    and restore r8 on both exit paths:
            bgt     3b
    -       ldmeqfd sp!, {r4-r7, pc}
    +       ldmeqfd sp!, {r4-r8, pc}
    (...)
            tst     r2, #16
            stmneia ip!, {r4-r7}
    -       ldmfd   sp!, {r4-r7, lr}
    +       ldmfd   sp!, {r4-r8, lr}
    
    Step 4
    ======
    Rewrite register list "r4-r7, r8" as "r4-r8".
    
    Signed-off-by: Ivan Djelic <ivan.djelic@parrot.com>
    Reviewed-by: Nicolas Pitre <nico@linaro.org>
    Signed-off-by: Dirk Behme <dirk.behme@gmail.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Cc: Eric Bénard <eric@eukrea.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit af15b7691766d99f0f84bae9b3444ab06e9beb29
Author: Steven Rostedt <rostedt@goodmis.org>
Date:   Wed Oct 9 22:23:23 2013 -0400

    tracing: Fix potential out-of-bounds in trace_get_user()
    
    commit 057db8488b53d5e4faa0cedb2f39d4ae75dfbdbb upstream.
    
    Andrey reported the following report:
    
    ERROR: AddressSanitizer: heap-buffer-overflow on address ffff8800359c99f3
    ffff8800359c99f3 is located 0 bytes to the right of 243-byte region [ffff8800359c9900, ffff8800359c99f3)
    Accessed by thread T13003:
      #0 ffffffff810dd2da (asan_report_error+0x32a/0x440)
      #1 ffffffff810dc6b0 (asan_check_region+0x30/0x40)
      #2 ffffffff810dd4d3 (__tsan_write1+0x13/0x20)
      #3 ffffffff811cd19e (ftrace_regex_release+0x1be/0x260)
      #4 ffffffff812a1065 (__fput+0x155/0x360)
      #5 ffffffff812a12de (____fput+0x1e/0x30)
      #6 ffffffff8111708d (task_work_run+0x10d/0x140)
      #7 ffffffff810ea043 (do_exit+0x433/0x11f0)
      #8 ffffffff810eaee4 (do_group_exit+0x84/0x130)
      #9 ffffffff810eafb1 (SyS_exit_group+0x21/0x30)
      #10 ffffffff81928782 (system_call_fastpath+0x16/0x1b)
    
    Allocated by thread T5167:
      #0 ffffffff810dc778 (asan_slab_alloc+0x48/0xc0)
      #1 ffffffff8128337c (__kmalloc+0xbc/0x500)
      #2 ffffffff811d9d54 (trace_parser_get_init+0x34/0x90)
      #3 ffffffff811cd7b3 (ftrace_regex_open+0x83/0x2e0)
      #4 ffffffff811cda7d (ftrace_filter_open+0x2d/0x40)
      #5 ffffffff8129b4ff (do_dentry_open+0x32f/0x430)
      #6 ffffffff8129b668 (finish_open+0x68/0xa0)
      #7 ffffffff812b66ac (do_last+0xb8c/0x1710)
      #8 ffffffff812b7350 (path_openat+0x120/0xb50)
      #9 ffffffff812b8884 (do_filp_open+0x54/0xb0)
      #10 ffffffff8129d36c (do_sys_open+0x1ac/0x2c0)
      #11 ffffffff8129d4b7 (SyS_open+0x37/0x50)
      #12 ffffffff81928782 (system_call_fastpath+0x16/0x1b)
    
    Shadow bytes around the buggy address:
      ffff8800359c9700: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
      ffff8800359c9780: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa
      ffff8800359c9800: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      ffff8800359c9880: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      ffff8800359c9900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>ffff8800359c9980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00[03]fb
      ffff8800359c9a00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      ffff8800359c9a80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      ffff8800359c9b00: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
      ffff8800359c9b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      ffff8800359c9c00: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07
      Heap redzone:          fa
      Heap kmalloc redzone:  fb
      Freed heap region:     fd
      Shadow gap:            fe
    
    The out-of-bounds access happens on 'parser->buffer[parser->idx] = 0;'
    
    Although the crash happened in ftrace_regex_open() the real bug
    occurred in trace_get_user() where there's an incrementation to
    parser->idx without a check against the size. The way it is triggered
    is if userspace sends in 128 characters (EVENT_BUF_SIZE + 1), the loop
    that reads the last character stores it and then breaks out because
    there is no more characters. Then the last character is read to determine
    what to do next, and the index is incremented without checking size.
    
    Then the caller of trace_get_user() usually nulls out the last character
    with a zero, but since the index is equal to the size, it writes a nul
    character after the allocated space, which can corrupt memory.
    
    Luckily, only root user has write access to this file.
    
    Link: http://lkml.kernel.org/r/20131009222323.04fd1a0d@gandalf.local.home
    
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9736cb3f9aa9c620965d937f4ff0261f6ac32ee1
Author: Patrick McHardy <kaber@trash.net>
Date:   Fri Apr 5 08:13:30 2013 +0000

    netfilter: nf_ct_sip: don't drop packets with offsets pointing outside the packet
    
    commit 3a7b21eaf4fb3c971bdb47a98f570550ddfe4471 upstream.
    
    Some Cisco phones create huge messages that are spread over multiple packets.
    After calculating the offset of the SIP body, it is validated to be within
    the packet and the packet is dropped otherwise. This breaks operation of
    these phones. Since connection tracking is supposed to be passive, just let
    those packets pass unmodified and untracked.
    
    Signed-off-by: Patrick McHardy <kaber@trash.net>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Cc: William Roberts <bill.c.roberts@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1ddb811a5471028b2c85c4d8515ce4ff65d867a1
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Jun 20 16:32:22 2012 +0200

    ALSA: hda - Move one-time init codes from generic_hdmi_init()
    
    commit 8b8d654b55648561287bd8baca0f75f964a17038 upstream.
    
    The codes to initialize work struct or create a proc interface should
    be called only once and never although it's called many times through
    the init callback.  Move that stuff into patch_generic_hdmi() so that
    it's called only once.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    BugLink: https://bugs.launchpad.net/bugs/1212160
    Signed-off-by: David Henningsson <david.henningsson@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a275776838715e6d7400b03414a23e99d6d85b8a
Author: Rui li <li.rui27@zte.com.cn>
Date:   Fri Oct 25 10:57:21 2013 +0800

    USB: add new zte 3g-dongle's pid to option.c
    
    commit 0636fc507a976cdc40f21bdbcce6f0b98ff1dfe9 upstream.
    
    Signed-off-by: Rui li <li.rui27@zte.com.cn>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c10141099c1ea42afa3ded64530cf285d8ffc96a
Author: Nikhil P Rao <nikhil.rao@intel.com>
Date:   Wed Jun 20 12:56:00 2012 -0700

    PCI: fix truncation of resource size to 32 bits
    
    commit d6776e6d5c2f8db0252f447b09736075e1bbe387 upstream.
    
    _pci_assign_resource() took an int "size" argument, which meant that
    sizes larger than 4GB were truncated.  Change type to resource_size_t.
    
    [bhelgaas: changelog]
    Signed-off-by: Nikhil P Rao <nikhil.rao@intel.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Cc: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 161f4a458cd88dc6ab33078d64aa28315129fade
Author: Jason Wang <jasowang@redhat.com>
Date:   Fri Nov 1 15:01:10 2013 +0800

    net: flow_dissector: fail on evil iph->ihl
    
    [ Upstream commit 6f092343855a71e03b8d209815d8c45bf3a27fcd ]
    
    We don't validate iph->ihl which may lead a dead loop if we meet a IPIP
    skb whose iph->ihl is zero. Fix this by failing immediately when iph->ihl
    is evil (less than 5).
    
    This issue were introduced by commit ec5efe7946280d1e84603389a1030ccec0a767ae
    (rps: support IPIP encapsulation).
    
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Cc: Eric Dumazet <edumazet@google.com>
    Cc: Petr Matousek <pmatouse@redhat.com>
    Cc: Michael S. Tsirkin <mst@redhat.com>
    Cc: Daniel Borkmann <dborkman@redhat.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2b58df72acb8525ea75947e75d2e79f76b240cca
Author: Wei Liu <wei.liu2@citrix.com>
Date:   Mon Oct 28 12:07:57 2013 +0000

    xen-netback: use jiffies_64 value to calculate credit timeout
    
    [ Upstream commit 059dfa6a93b779516321e5112db9d7621b1367ba ]
    
    time_after_eq() only works if the delta is < MAX_ULONG/2.
    
    For a 32bit Dom0, if netfront sends packets at a very low rate, the time
    between subsequent calls to tx_credit_exceeded() may exceed MAX_ULONG/2
    and the test for timer_after_eq() will be incorrect. Credit will not be
    replenished and the guest may become unable to send packets (e.g., if
    prior to the long gap, all credit was exhausted).
    
    Use jiffies_64 variant to mitigate this problem for 32bit Dom0.
    
    Suggested-by: Jan Beulich <jbeulich@suse.com>
    Signed-off-by: Wei Liu <wei.liu2@citrix.com>
    Reviewed-by: David Vrabel <david.vrabel@citrix.com>
    Cc: Ian Campbell <ian.campbell@citrix.com>
    Cc: Jason Luan <jianhai.luan@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>