commit 982ce2aa79fbe7c961ee948857d5b5b2a0b2ddd9
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Aug 24 17:02:58 2017 -0700

    Linux 4.4.84

commit ccf1033d99834d5ead622542b325e0f063caf05e
Author: Hector Martin <marcan@marcan.st>
Date:   Wed Aug 2 00:45:44 2017 +0900

    usb: qmi_wwan: add D-Link DWM-222 device ID
    
    commit bed9ff165960921303a100228585f2d1691b42eb upstream.
    
    Signed-off-by: Hector Martin <marcan@marcan.st>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b45092236817efd713e92beab934fe404393324
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Fri Jun 2 16:36:26 2017 +0300

    usb: optimize acpi companion search for usb port devices
    
    commit ed18c5fa945768a9bec994e786edbbbc7695acf6 upstream.
    
    This optimization significantly reduces xhci driver load time.
    
    In ACPI tables the acpi companion port devices are children of
    the hub device. The port devices are identified by their port number
    returned by the ACPI _ADR method.
    _ADR 0 is reserved for the root hub device.
    
    The current implementation to find a acpi companion port device
    loops through all acpi port devices under that parent hub, evaluating
    their _ADR method each time a new port device is added.
    
    for a xHC controller with 25 ports under its roothub it
    will end up invoking ACPI bytecode 625 times before all ports
    are ready, making it really slow.
    
    The _ADR values are already read and cached earler. So instead of
    running the bytecode again we can check the cached _ADR value first,
    and then fall back to the old way.
    
    As one of the more significant changes, the xhci load time on
    Intel kabylake reduced by 70%, (28ms) from
    initcall xhci_pci_init+0x0/0x49 returned 0 after 39537 usecs
    to
    initcall xhci_pci_init+0x0/0x49 returned 0 after 11270 usecs
    
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ce1b98a30571b1022d6ce86d9876a7a7dbf9aed5
Author: Stephane Eranian <eranian@google.com>
Date:   Thu Dec 3 23:33:17 2015 +0100

    perf/x86: Fix LBR related crashes on Intel Atom
    
    commit 6fc2e83077b05a061afe9b24f2fdff7a0434eb67 upstream.
    
    This patches fixes the LBR kernel crashes on Intel Atom.
    
    The kernel was assuming that if the CPU supports 64-bit format
    LBR, then it has an LBR_SELECT MSR. Atom uses 64-bit LBR format
    but does not have LBR_SELECT. That was causing NULL pointer
    dereferences in a couple of places.
    
    Signed-off-by: Stephane Eranian <eranian@google.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Vince Weaver <vincent.weaver@maine.edu>
    Cc: kan.liang@intel.com
    Fixes: 96f3eda67fcf ("perf/x86/intel: Fix static checker warning in lbr enable")
    Link: http://lkml.kernel.org/r/1449182000-31524-2-git-send-email-eranian@google.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Denys Zagorui <dzagorui@cisco.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b4cf49024cf412a94121e61f8056636c557ead98
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Mon Aug 21 17:35:02 2017 +0200

    pids: make task_tgid_nr_ns() safe
    
    commit dd1c1f2f2028a7b851f701fc6a8ebe39dcb95e7c upstream.
    
    This was reported many times, and this was even mentioned in commit
    52ee2dfdd4f5 ("pids: refactor vnr/nr_ns helpers to make them safe") but
    somehow nobody bothered to fix the obvious problem: task_tgid_nr_ns() is
    not safe because task->group_leader points to nowhere after the exiting
    task passes exit_notify(), rcu_read_lock() can not help.
    
    We really need to change __unhash_process() to nullify group_leader,
    parent, and real_parent, but this needs some cleanups.  Until then we
    can turn task_tgid_nr_ns() into another user of __task_pid_nr_ns() and
    fix the problem.
    
    Reported-by: Troy Kensinger <tkensinger@google.com>
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 46d51a26efbc7cbaa2bc1f01628a00a604193856
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sun Aug 20 13:26:27 2017 -0700

    Sanitize 'move_pages()' permission checks
    
    commit 197e7e521384a23b9e585178f3f11c9fa08274b9 upstream.
    
    The 'move_paghes()' system call was introduced long long ago with the
    same permission checks as for sending a signal (except using
    CAP_SYS_NICE instead of CAP_SYS_KILL for the overriding capability).
    
    That turns out to not be a great choice - while the system call really
    only moves physical page allocations around (and you need other
    capabilities to do a lot of it), you can check the return value to map
    out some the virtual address choices and defeat ASLR of a binary that
    still shares your uid.
    
    So change the access checks to the more common 'ptrace_may_access()'
    model instead.
    
    This tightens the access checks for the uid, and also effectively
    changes the CAP_SYS_NICE check to CAP_SYS_PTRACE, but it's unlikely that
    anybody really _uses_ this legacy system call any more (we hav ebetter
    NUMA placement models these days), so I expect nobody to notice.
    
    Famous last words.
    
    Reported-by: Otto Ebeling <otto.ebeling@iki.fi>
    Acked-by: Eric W. Biederman <ebiederm@xmission.com>
    Cc: Willy Tarreau <w@1wt.eu>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b27e9ff9a5f457e85c47733387426bf522cef2aa
Author: Boris Brezillon <boris.brezillon@free-electrons.com>
Date:   Tue Jul 4 11:10:40 2017 +0200

    irqchip/atmel-aic: Fix unbalanced refcount in aic_common_rtc_irq_fixup()
    
    commit 277867ade8262583f4280cadbe90e0031a3706a7 upstream.
    
    of_find_compatible_node() is calling of_node_put() on its first argument
    thus leading to an unbalanced of_node_get/put() issue if the node has not
    been retained before that.
    
    Instead of passing the root node, pass NULL, which does exactly the same:
    iterate over all DT nodes, starting from the root node.
    
    Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
    Reported-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
    Fixes: 3d61467f9bab ("irqchip: atmel-aic: Implement RTC irq fixup")
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ed281a6acaf1260800841fc8182e6a8b1d1b1371
Author: Boris Brezillon <boris.brezillon@free-electrons.com>
Date:   Tue Jul 4 11:10:39 2017 +0200

    irqchip/atmel-aic: Fix unbalanced of_node_put() in aic_common_irq_fixup()
    
    commit 469bcef53c546bb792aa66303933272991b7831d upstream.
    
    aic_common_irq_fixup() is calling twice of_node_put() on the same node
    thus leading to an unbalanced refcount on the root node.
    
    Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
    Reported-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
    Fixes: b2f579b58e93 ("irqchip: atmel-aic: Add irq fixup infrastructure")
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 64340986295dea6cf954caa630000a77775f9975
Author: Andy Lutomirski <luto@kernel.org>
Date:   Mon Aug 7 19:43:13 2017 -0700

    x86/asm/64: Clear AC on NMI entries
    
    commit e93c17301ac55321fc18e0f8316e924e58a83c8c upstream.
    
    This closes a hole in our SMAP implementation.
    
    This patch comes from grsecurity. Good catch!
    
    Signed-off-by: Andy Lutomirski <luto@kernel.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Brian Gerst <brgerst@gmail.com>
    Cc: Denys Vlasenko <dvlasenk@redhat.com>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/314cc9f294e8f14ed85485727556ad4f15bb1659.1502159503.git.luto@kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c0b397fd6b2b8ed7b39a717340b85b4b1add5332
Author: Roger Pau Monne <roger.pau@citrix.com>
Date:   Tue Jul 18 15:01:00 2017 +0100

    xen: fix bio vec merging
    
    commit 462cdace790ac2ed6aad1b19c9c0af0143b6aab0 upstream.
    
    The current test for bio vec merging is not fully accurate and can be
    tricked into merging bios when certain grant combinations are used.
    The result of these malicious bio merges is a bio that extends past
    the memory page used by any of the originating bios.
    
    Take into account the following scenario, where a guest creates two
    grant references that point to the same mfn, ie: grant 1 -> mfn A,
    grant 2 -> mfn A.
    
    These references are then used in a PV block request, and mapped by
    the backend domain, thus obtaining two different pfns that point to
    the same mfn, pfn B -> mfn A, pfn C -> mfn A.
    
    If those grants happen to be used in two consecutive sectors of a disk
    IO operation becoming two different bios in the backend domain, the
    checks in xen_biovec_phys_mergeable will succeed, because bfn1 == bfn2
    (they both point to the same mfn). However due to the bio merging,
    the backend domain will end up with a bio that expands past mfn A into
    mfn A + 1.
    
    Fix this by making sure the check in xen_biovec_phys_mergeable takes
    into account the offset and the length of the bio, this basically
    replicates whats done in __BIOVEC_PHYS_MERGEABLE using mfns (bus
    addresses). While there also remove the usage of
    __BIOVEC_PHYS_MERGEABLE, since that's already checked by the callers
    of xen_biovec_phys_mergeable.
    
    Reported-by: "Jan H. Schönherr" <jschoenh@amazon.de>
    Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 240628085effc47e86f51fc3fb37bc0e628f9a85
Author: Kees Cook <keescook@chromium.org>
Date:   Fri Aug 18 15:16:31 2017 -0700

    mm: revert x86_64 and arm64 ELF_ET_DYN_BASE base changes
    
    commit c715b72c1ba406f133217b509044c38d8e714a37 upstream.
    
    Moving the x86_64 and arm64 PIE base from 0x555555554000 to 0x000100000000
    broke AddressSanitizer.  This is a partial revert of:
    
      eab09532d400 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE")
      02445990a96e ("arm64: move ELF_ET_DYN_BASE to 4GB / 4MB")
    
    The AddressSanitizer tool has hard-coded expectations about where
    executable mappings are loaded.
    
    The motivation for changing the PIE base in the above commits was to
    avoid the Stack-Clash CVEs that allowed executable mappings to get too
    close to heap and stack.  This was mainly a problem on 32-bit, but the
    64-bit bases were moved too, in an effort to proactively protect those
    systems (proofs of concept do exist that show 64-bit collisions, but
    other recent changes to fix stack accounting and setuid behaviors will
    minimize the impact).
    
    The new 32-bit PIE base is fine for ASan (since it matches the ET_EXEC
    base), so only the 64-bit PIE base needs to be reverted to let x86 and
    arm64 ASan binaries run again.  Future changes to the 64-bit PIE base on
    these architectures can be made optional once a more dynamic method for
    dealing with AddressSanitizer is found.  (e.g.  always loading PIE into
    the mmap region for marked binaries.)
    
    Link: http://lkml.kernel.org/r/20170807201542.GA21271@beast
    Fixes: eab09532d400 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE")
    Fixes: 02445990a96e ("arm64: move ELF_ET_DYN_BASE to 4GB / 4MB")
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Reported-by: Kostya Serebryany <kcc@google.com>
    Acked-by: Will Deacon <will.deacon@arm.com>
    Cc: Ingo Molnar <mingo@elte.hu>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    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 cc971fa12bd2dff6c0432c860d784c6cdaf5a04b
Author: zhong jiang <zhongjiang@huawei.com>
Date:   Fri Aug 18 15:16:24 2017 -0700

    mm/mempolicy: fix use after free when calling get_mempolicy
    
    commit 73223e4e2e3867ebf033a5a8eb2e5df0158ccc99 upstream.
    
    I hit a use after free issue when executing trinity and repoduced it
    with KASAN enabled.  The related call trace is as follows.
    
      BUG: KASan: use after free in SyS_get_mempolicy+0x3c8/0x960 at addr ffff8801f582d766
      Read of size 2 by task syz-executor1/798
    
      INFO: Allocated in mpol_new.part.2+0x74/0x160 age=3 cpu=1 pid=799
         __slab_alloc+0x768/0x970
         kmem_cache_alloc+0x2e7/0x450
         mpol_new.part.2+0x74/0x160
         mpol_new+0x66/0x80
         SyS_mbind+0x267/0x9f0
         system_call_fastpath+0x16/0x1b
      INFO: Freed in __mpol_put+0x2b/0x40 age=4 cpu=1 pid=799
         __slab_free+0x495/0x8e0
         kmem_cache_free+0x2f3/0x4c0
         __mpol_put+0x2b/0x40
         SyS_mbind+0x383/0x9f0
         system_call_fastpath+0x16/0x1b
      INFO: Slab 0xffffea0009cb8dc0 objects=23 used=8 fp=0xffff8801f582de40 flags=0x200000000004080
      INFO: Object 0xffff8801f582d760 @offset=5984 fp=0xffff8801f582d600
    
      Bytes b4 ffff8801f582d750: ae 01 ff ff 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a  ........ZZZZZZZZ
      Object ffff8801f582d760: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
      Object ffff8801f582d770: 6b 6b 6b 6b 6b 6b 6b a5                          kkkkkkk.
      Redzone ffff8801f582d778: bb bb bb bb bb bb bb bb                          ........
      Padding ffff8801f582d8b8: 5a 5a 5a 5a 5a 5a 5a 5a                          ZZZZZZZZ
      Memory state around the buggy address:
      ffff8801f582d600: fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc fc
      ffff8801f582d680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      >ffff8801f582d700: fc fc fc fc fc fc fc fc fc fc fc fc fb fb fb fc
    
    !shared memory policy is not protected against parallel removal by other
    thread which is normally protected by the mmap_sem.  do_get_mempolicy,
    however, drops the lock midway while we can still access it later.
    
    Early premature up_read is a historical artifact from times when
    put_user was called in this path see https://lwn.net/Articles/124754/
    but that is gone since 8bccd85ffbaf ("[PATCH] Implement sys_* do_*
    layering in the memory policy layer.").  but when we have the the
    current mempolicy ref count model.  The issue was introduced
    accordingly.
    
    Fix the issue by removing the premature release.
    
    Link: http://lkml.kernel.org/r/1502950924-27521-1-git-send-email-zhongjiang@huawei.com
    Signed-off-by: zhong jiang <zhongjiang@huawei.com>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Cc: Minchan Kim <minchan@kernel.org>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Mel Gorman <mgorman@techsingularity.net>
    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 669c8ab896a2f96a1d49cfa1f5efaaf64c0f6aaa
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Aug 16 14:18:37 2017 +0200

    ALSA: usb-audio: Add mute TLV for playback volumes on C-Media devices
    
    commit 0f174b3525a43bd51f9397394763925e0ebe7bc7 upstream.
    
    C-Media devices (at least some models) mute the playback stream when
    volumes are set to the minimum value.  But this isn't informed via TLV
    and the user-space, typically PulseAudio, gets confused as if it's
    still played in a low volume.
    
    This patch adds the new flag, min_mute, to struct usb_mixer_elem_info
    for indicating that the mixer element is with the minimum-mute volume.
    This flag is set for known C-Media devices in
    snd_usb_mixer_fu_apply_quirk() in turn.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=196669
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f600f9c43346a7f26e9b808b827adfaf5e73958b
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Aug 14 14:35:50 2017 +0200

    ALSA: usb-audio: Apply sample rate quirk to Sennheiser headset
    
    commit a8e800fe0f68bc28ce309914f47e432742b865ed upstream.
    
    A Senheisser headset requires the typical sample-rate quirk for
    avoiding spurious errors from inquiring the current sample rate like:
     usb 1-1: 2:1: cannot get freq at ep 0x4
     usb 1-1: 3:1: cannot get freq at ep 0x83
    
    The USB ID 1395:740a has to be added to the entries in
    snd_usb_get_sample_rate_quirk().
    
    Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1052580
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 735aa043bf00c809a93d01c7ef4039115f1ef590
Author: Daniel Mentz <danielmentz@google.com>
Date:   Mon Aug 14 14:46:01 2017 -0700

    ALSA: seq: 2nd attempt at fixing race creating a queue
    
    commit 7e1d90f60a0d501c8503e636942ca704a454d910 upstream.
    
    commit 4842e98f26dd80be3623c4714a244ba52ea096a8 ("ALSA: seq: Fix race at
    creating a queue") attempted to fix a race reported by syzkaller. That
    fix has been described as follows:
    
    "
    When a sequencer queue is created in snd_seq_queue_alloc(),it adds the
    new queue element to the public list before referencing it.  Thus the
    queue might be deleted before the call of snd_seq_queue_use(), and it
    results in the use-after-free error, as spotted by syzkaller.
    
    The fix is to reference the queue object at the right time.
    "
    
    Even with that fix in place, syzkaller reported a use-after-free error.
    It specifically pointed to the last instruction "return q->queue" in
    snd_seq_queue_alloc(). The pointer q is being used after kfree() has
    been called on it.
    
    It turned out that there is still a small window where a race can
    happen. The window opens at
    snd_seq_ioctl_create_queue()->snd_seq_queue_alloc()->queue_list_add()
    and closes at
    snd_seq_ioctl_create_queue()->queueptr()->snd_use_lock_use(). Between
    these two calls, a different thread could delete the queue and possibly
    re-create a different queue in the same location in queue_list.
    
    This change prevents this situation by calling snd_use_lock_use() from
    snd_seq_queue_alloc() prior to calling queue_list_add(). It is then the
    caller's responsibility to call snd_use_lock_free(&q->use_lock).
    
    Fixes: 4842e98f26dd ("ALSA: seq: Fix race at creating a queue")
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Daniel Mentz <danielmentz@google.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ae4743cac8d771a614da982ed51ffd396041c3ec
Author: KT Liao <kt.liao@emc.com.tw>
Date:   Mon Aug 14 20:11:59 2017 -0700

    Input: elan_i2c - Add antoher Lenovo ACPI ID for upcoming Lenovo NB
    
    commit 76988690402dde2880bfe06ecccf381d48ba8e1c upstream.
    
    Add 2 new IDs (ELAN0609 and ELAN060B) to the list of ACPI IDs that should
    be handled by the driver.
    
    Signed-off-by: KT Liao <kt.liao@emc.com.tw>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0dbf7f7811df34f0e6af97b885619780014f81e1
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Mon Aug 14 20:11:26 2017 -0700

    Input: elan_i2c - add ELAN0608 to the ACPI table
    
    commit 1874064eed0502bd9bef7be8023757b0c4f26883 upstream.
    
    Similar to commit 722c5ac708b4f ("Input: elan_i2c - add ELAN0605 to the
    ACPI table"), ELAN0608 should be handled by elan_i2c.
    
    This touchpad can be found in Lenovo ideapad 320-14IKB.
    
    BugLink: https://bugs.launchpad.net/bugs/1708852
    
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4362533a04680de13acd3e6f5a16c3d81502f589
Author: megha.dey@linux.intel.com <megha.dey@linux.intel.com>
Date:   Wed Aug 2 13:49:09 2017 -0700

    crypto: x86/sha1 - Fix reads beyond the number of blocks passed
    
    commit 8861249c740fc4af9ddc5aee321eafefb960d7c6 upstream.
    
    It was reported that the sha1 AVX2 function(sha1_transform_avx2) is
    reading ahead beyond its intended data, and causing a crash if the next
    block is beyond page boundary:
    http://marc.info/?l=linux-crypto-vger&m=149373371023377
    
    This patch makes sure that there is no overflow for any buffer length.
    
    It passes the tests written by Jan Stancek that revealed this problem:
    https://github.com/jstancek/sha1-avx2-crash
    
    I have re-enabled sha1-avx2 by reverting commit
    b82ce24426a4071da9529d726057e4e642948667
    
    Fixes: b82ce24426a4 ("crypto: sha1-ssse3 - Disable avx2")
    Originally-by: Ilya Albrekht <ilya.albrekht@intel.com>
    Tested-by: Jan Stancek <jstancek@redhat.com>
    Signed-off-by: Megha Dey <megha.dey@linux.intel.com>
    Reported-by: Jan Stancek <jstancek@redhat.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 04f4f73ffe9383921794b833346911bd1e19b228
Author: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Date:   Sat Aug 12 23:36:47 2017 +0200

    parisc: pci memory bar assignment fails with 64bit kernels on dino/cujo
    
    commit 4098116039911e8870d84c975e2ec22dab65a909 upstream.
    
    For 64bit kernels the lmmio_space_offset of the host bridge window
    isn't set correctly on systems with dino/cujo PCI host bridges.
    This leads to not assigned memory bars and failing drivers, which
    need to use these bars.
    
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Acked-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea088172692cbadddc4efcdae2a5dfe1693e8b20
Author: Jan Kara <jack@suse.cz>
Date:   Tue Aug 15 13:00:36 2017 +0200

    audit: Fix use after free in audit_remove_watch_rule()
    
    commit d76036ab47eafa6ce52b69482e91ca3ba337d6d6 upstream.
    
    audit_remove_watch_rule() drops watch's reference to parent but then
    continues to work with it. That is not safe as parent can get freed once
    we drop our reference. The following is a trivial reproducer:
    
    mount -o loop image /mnt
    touch /mnt/file
    auditctl -w /mnt/file -p wax
    umount /mnt
    auditctl -D
    <crash in fsnotify_destroy_mark()>
    
    Grab our own reference in audit_remove_watch_rule() earlier to make sure
    mark does not get freed under us.
    
    Reported-by: Tony Jones <tonyj@suse.de>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Tested-by: Tony Jones <tonyj@suse.de>
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b72f1119c654a2e3aeb41175ff94299a4ec01afb
Author: Liping Zhang <zlpnobody@gmail.com>
Date:   Sat Mar 25 16:35:29 2017 +0800

    netfilter: nf_ct_ext: fix possible panic after nf_ct_extend_unregister
    
    commit 9c3f3794926a997b1cab6c42480ff300efa2d162 upstream.
    
    If one cpu is doing nf_ct_extend_unregister while another cpu is doing
    __nf_ct_ext_add_length, then we may hit BUG_ON(t == NULL). Moreover,
    there's no synchronize_rcu invocation after set nf_ct_ext_types[id] to
    NULL, so it's possible that we may access invalid pointer.
    
    But actually, most of the ct extends are built-in, so the problem listed
    above will not happen. However, there are two exceptions: NF_CT_EXT_NAT
    and NF_CT_EXT_SYNPROXY.
    
    For _EXT_NAT, the panic will not happen, since adding the nat extend and
    unregistering the nat extend are located in the same file(nf_nat_core.c),
    this means that after the nat module is removed, we cannot add the nat
    extend too.
    
    For _EXT_SYNPROXY, synproxy extend may be added by init_conntrack, while
    synproxy extend unregister will be done by synproxy_core_exit. So after
    nf_synproxy_core.ko is removed, we may still try to add the synproxy
    extend, then kernel panic may happen.
    
    I know it's very hard to reproduce this issue, but I can play a tricky
    game to make it happen very easily :)
    
    Step 1. Enable SYNPROXY for tcp dport 1234 at FORWARD hook:
      # iptables -I FORWARD -p tcp --dport 1234 -j SYNPROXY
    Step 2. Queue the syn packet to the userspace at raw table OUTPUT hook.
            Also note, in the userspace we only add a 20s' delay, then
            reinject the syn packet to the kernel:
      # iptables -t raw -I OUTPUT -p tcp --syn -j NFQUEUE --queue-num 1
    Step 3. Using "nc 2.2.2.2 1234" to connect the server.
    Step 4. Now remove the nf_synproxy_core.ko quickly:
      # iptables -F FORWARD
      # rmmod ipt_SYNPROXY
      # rmmod nf_synproxy_core
    Step 5. After 20s' delay, the syn packet is reinjected to the kernel.
    
    Now you will see the panic like this:
      kernel BUG at net/netfilter/nf_conntrack_extend.c:91!
      Call Trace:
       ? __nf_ct_ext_add_length+0x53/0x3c0 [nf_conntrack]
       init_conntrack+0x12b/0x600 [nf_conntrack]
       nf_conntrack_in+0x4cc/0x580 [nf_conntrack]
       ipv4_conntrack_local+0x48/0x50 [nf_conntrack_ipv4]
       nf_reinject+0x104/0x270
       nfqnl_recv_verdict+0x3e1/0x5f9 [nfnetlink_queue]
       ? nfqnl_recv_verdict+0x5/0x5f9 [nfnetlink_queue]
       ? nla_parse+0xa0/0x100
       nfnetlink_rcv_msg+0x175/0x6a9 [nfnetlink]
       [...]
    
    One possible solution is to make NF_CT_EXT_SYNPROXY extend built-in, i.e.
    introduce nf_conntrack_synproxy.c and only do ct extend register and
    unregister in it, similar to nf_conntrack_timeout.c.
    
    But having such a obscure restriction of nf_ct_extend_unregister is not a
    good idea, so we should invoke synchronize_rcu after set nf_ct_ext_types
    to NULL, and check the NULL pointer when do __nf_ct_ext_add_length. Then
    it will be easier if we add new ct extend in the future.
    
    Last, we use kfree_rcu to free nf_ct_ext, so rcu_barrier() is unnecessary
    anymore, remove it too.
    
    Signed-off-by: Liping Zhang <zlpnobody@gmail.com>
    Acked-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Cc: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>