commit b87af3ab9dae0dc53b201701725ed6e2af4f2f74
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri May 25 10:54:58 2018 +0200

    Linux 3.18.110

commit b233cc9c11ba38e90145db370948ab810d6020da
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Wed May 9 19:42:20 2018 +0900

    x86/kexec: Avoid double free_page() upon do_kexec_load() failure
    
    commit a466ef76b815b86748d9870ef2a430af7b39c710 upstream.
    
    >From ff82bedd3e12f0d3353282054ae48c3bd8c72012 Mon Sep 17 00:00:00 2001
    From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Date: Wed, 9 May 2018 12:12:39 +0900
    Subject: x86/kexec: Avoid double free_page() upon do_kexec_load() failure
    
    syzbot is reporting crashes after memory allocation failure inside
    do_kexec_load() [1]. This is because free_transition_pgtable() is called
    by both init_transition_pgtable() and machine_kexec_cleanup() when memory
    allocation failed inside init_transition_pgtable().
    
    Regarding 32bit code, machine_kexec_free_page_tables() is called by both
    machine_kexec_alloc_page_tables() and machine_kexec_cleanup() when memory
    allocation failed inside machine_kexec_alloc_page_tables().
    
    Fix this by leaving the error handling to machine_kexec_cleanup()
    (and optionally setting NULL after free_page()).
    
    [1] https://syzkaller.appspot.com/bug?id=91e52396168cf2bdd572fe1e1bc0bc645c1c6b40
    
    Fixes: f5deb79679af6eb4 ("x86: kexec: Use one page table in x86_64 machine_kexec")
    Fixes: 92be3d6bdf2cb349 ("kexec/i386: allocate page table pages dynamically")
    Reported-by: syzbot <syzbot+d96f60296ef613fe1d69@syzkaller.appspotmail.com>
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Baoquan He <bhe@redhat.com>
    Cc: thomas.lendacky@amd.com
    Cc: prudo@linux.vnet.ibm.com
    Cc: Huang Ying <ying.huang@intel.com>
    Cc: syzkaller-bugs@googlegroups.com
    Cc: takahiro.akashi@linaro.org
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: akpm@linux-foundation.org
    Cc: dyoung@redhat.com
    Cc: kirill.shutemov@linux.intel.com
    Link: https://lkml.kernel.org/r/201805091942.DGG12448.tMFVFSJFQOOLHO@I-love.SAKURA.ne.jp
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f9322eb90b66bd615ce624cc94fb7a455f311b84
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Fri May 18 16:09:16 2018 -0700

    hfsplus: stop workqueue when fill_super() failed
    
    commit 66072c29328717072fd84aaff3e070e3f008ba77 upstream.
    
    syzbot is reporting ODEBUG messages at hfsplus_fill_super() [1].  This
    is because hfsplus_fill_super() forgot to call cancel_delayed_work_sync().
    
    As far as I can see, it is hfsplus_mark_mdb_dirty() from
    hfsplus_new_inode() in hfsplus_fill_super() that calls
    queue_delayed_work().  Therefore, I assume that hfsplus_new_inode() does
    not fail if queue_delayed_work() was called, and the out_put_hidden_dir
    label is the appropriate location to call cancel_delayed_work_sync().
    
    [1] https://syzkaller.appspot.com/bug?id=a66f45e96fdbeb76b796bf46eb25ea878c42a6c9
    
    Link: http://lkml.kernel.org/r/964a8b27-cd69-357c-fe78-76b066056201@I-love.SAKURA.ne.jp
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Reported-by: syzbot <syzbot+4f2e5f086147d543ab03@syzkaller.appspotmail.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: David Howells <dhowells@redhat.com>
    Cc: Ernesto A. Fernandez <ernesto.mnd.fernandez@gmail.com>
    Cc: Vyacheslav Dubeyko <slava@dubeyko.com>
    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 a77831e13f9068dc2b3b3f3965323015fb527f4c
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue Apr 3 14:33:49 2018 +0200

    cfg80211: limit wiphy names to 128 bytes
    
    commit a7cfebcb7594a24609268f91299ab85ba064bf82 upstream.
    
    There's currently no limit on wiphy names, other than netlink
    message size and memory limitations, but that causes issues when,
    for example, the wiphy name is used in a uevent, e.g. in rfkill
    where we use the same name for the rfkill instance, and then the
    buffer there is "only" 2k for the environment variables.
    
    This was reported by syzkaller, which used a 4k name.
    
    Limit the name to something reasonable, I randomly picked 128.
    
    Reported-by: syzbot+230d9e642a85d3fec29c@syzkaller.appspotmail.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 58b7ce6f9ef2367f86384b20458642945993b816
Author: Alexander Potapenko <glider@google.com>
Date:   Fri May 18 16:23:18 2018 +0200

    scsi: sg: allocate with __GFP_ZERO in sg_build_indirect()
    
    commit a45b599ad808c3c982fdcdc12b0b8611c2f92824 upstream.
    
    This shall help avoid copying uninitialized memory to the userspace when
    calling ioctl(fd, SG_IO) with an empty command.
    
    Reported-by: syzbot+7d26fc1eea198488deab@syzkaller.appspotmail.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Alexander Potapenko <glider@google.com>
    Acked-by: Douglas Gilbert <dgilbert@interlog.com>
    Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit badf15c8a243ca1292b8034dea2f91cc01982010
Author: Jason Yan <yanaijie@huawei.com>
Date:   Thu Mar 8 10:34:53 2018 +0800

    scsi: libsas: defer ata device eh commands to libata
    
    commit 318aaf34f1179b39fa9c30fa0f3288b645beee39 upstream.
    
    When ata device doing EH, some commands still attached with tasks are
    not passed to libata when abort failed or recover failed, so libata did
    not handle these commands. After these commands done, sas task is freed,
    but ata qc is not freed. This will cause ata qc leak and trigger a
    warning like below:
    
    WARNING: CPU: 0 PID: 28512 at drivers/ata/libata-eh.c:4037
    ata_eh_finish+0xb4/0xcc
    CPU: 0 PID: 28512 Comm: kworker/u32:2 Tainted: G     W  OE 4.14.0#1
    ......
    Call trace:
    [<ffff0000088b7bd0>] ata_eh_finish+0xb4/0xcc
    [<ffff0000088b8420>] ata_do_eh+0xc4/0xd8
    [<ffff0000088b8478>] ata_std_error_handler+0x44/0x8c
    [<ffff0000088b8068>] ata_scsi_port_error_handler+0x480/0x694
    [<ffff000008875fc4>] async_sas_ata_eh+0x4c/0x80
    [<ffff0000080f6be8>] async_run_entry_fn+0x4c/0x170
    [<ffff0000080ebd70>] process_one_work+0x144/0x390
    [<ffff0000080ec100>] worker_thread+0x144/0x418
    [<ffff0000080f2c98>] kthread+0x10c/0x138
    [<ffff0000080855dc>] ret_from_fork+0x10/0x18
    
    If ata qc leaked too many, ata tag allocation will fail and io blocked
    for ever.
    
    As suggested by Dan Williams, defer ata device commands to libata and
    merge sas_eh_finish_cmd() with sas_eh_defer_cmd(). libata will handle
    ata qcs correctly after this.
    
    Signed-off-by: Jason Yan <yanaijie@huawei.com>
    CC: Xiaofei Tan <tanxiaofei@huawei.com>
    CC: John Garry <john.garry@huawei.com>
    CC: Dan Williams <dan.j.williams@intel.com>
    Reviewed-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f7a4463d57ca32dd1fad77c83b3730d7d023ac15
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Thu May 17 17:18:30 2018 -0400

    ext2: fix a block leak
    
    commit 5aa1437d2d9a068c0334bd7c9dafa8ec4f97f13b upstream.
    
    open file, unlink it, then use ioctl(2) to make it immutable or
    append only.  Now close it and watch the blocks *not* freed...
    
    Immutable/append-only checks belong in ->setattr().
    Note: the bug is old and backport to anything prior to 737f2e93b972
    ("ext2: convert to use the new truncate convention") will need
    these checks lifted into ext2_setattr().
    
    Cc: stable@kernel.org
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 85611642047443ea8567f5cccc4c282fedde11b6
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon May 14 21:14:26 2018 -0700

    tcp: purge write queue in tcp_connect_init()
    
    [ Upstream commit 7f582b248d0a86bae5788c548d7bb5bca6f7691a ]
    
    syzkaller found a reliable way to crash the host, hitting a BUG()
    in __tcp_retransmit_skb()
    
    Malicous MSG_FASTOPEN is the root cause. We need to purge write queue
    in tcp_connect_init() at the point we init snd_una/write_seq.
    
    This patch also replaces the BUG() by a less intrusive WARN_ON_ONCE()
    
    kernel BUG at net/ipv4/tcp_output.c:2837!
    invalid opcode: 0000 [#1] SMP KASAN
    Dumping ftrace buffer:
       (ftrace buffer empty)
    Modules linked in:
    CPU: 0 PID: 5276 Comm: syz-executor0 Not tainted 4.17.0-rc3+ #51
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    RIP: 0010:__tcp_retransmit_skb+0x2992/0x2eb0 net/ipv4/tcp_output.c:2837
    RSP: 0000:ffff8801dae06ff8 EFLAGS: 00010206
    RAX: ffff8801b9fe61c0 RBX: 00000000ffc18a16 RCX: ffffffff864e1a49
    RDX: 0000000000000100 RSI: ffffffff864e2e12 RDI: 0000000000000005
    RBP: ffff8801dae073a0 R08: ffff8801b9fe61c0 R09: ffffed0039c40dd2
    R10: ffffed0039c40dd2 R11: ffff8801ce206e93 R12: 00000000421eeaad
    R13: ffff8801ce206d4e R14: ffff8801ce206cc0 R15: ffff8801cd4f4a80
    FS:  0000000000000000(0000) GS:ffff8801dae00000(0063) knlGS:00000000096bc900
    CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
    CR2: 0000000020000000 CR3: 00000001c47b6000 CR4: 00000000001406f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <IRQ>
     tcp_retransmit_skb+0x2e/0x250 net/ipv4/tcp_output.c:2923
     tcp_retransmit_timer+0xc50/0x3060 net/ipv4/tcp_timer.c:488
     tcp_write_timer_handler+0x339/0x960 net/ipv4/tcp_timer.c:573
     tcp_write_timer+0x111/0x1d0 net/ipv4/tcp_timer.c:593
     call_timer_fn+0x230/0x940 kernel/time/timer.c:1326
     expire_timers kernel/time/timer.c:1363 [inline]
     __run_timers+0x79e/0xc50 kernel/time/timer.c:1666
     run_timer_softirq+0x4c/0x70 kernel/time/timer.c:1692
     __do_softirq+0x2e0/0xaf5 kernel/softirq.c:285
     invoke_softirq kernel/softirq.c:365 [inline]
     irq_exit+0x1d1/0x200 kernel/softirq.c:405
     exiting_irq arch/x86/include/asm/apic.h:525 [inline]
     smp_apic_timer_interrupt+0x17e/0x710 arch/x86/kernel/apic/apic.c:1052
     apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863
    
    Fixes: cf60af03ca4e ("net-tcp: Fast Open client - sendmsg(MSG_FASTOPEN)")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Yuchung Cheng <ycheng@google.com>
    Cc: Neal Cardwell <ncardwell@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 332d1b9337db48b15875298e586e98ab7bceb4ff
Author: Willem de Bruijn <willemb@google.com>
Date:   Thu May 17 13:13:29 2018 -0400

    net: test tailroom before appending to linear skb
    
    [ Upstream commit 113f99c3358564a0647d444c2ae34e8b1abfd5b9 ]
    
    Device features may change during transmission. In particular with
    corking, a device may toggle scatter-gather in between allocating
    and writing to an skb.
    
    Do not unconditionally assume that !NETIF_F_SG at write time implies
    that the same held at alloc time and thus the skb has sufficient
    tailroom.
    
    This issue predates git history.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Reviewed-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 21bcf304a8b9dfadf7fcaccaa44f41110edd21cb
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Sun May 13 05:04:29 2018 +0100

    ARM: 8772/1: kprobes: Prohibit kprobes on get_user functions
    
    commit 0d73c3f8e7f6ee2aab1bb350f60c180f5ae21a2c upstream.
    
    Since do_undefinstr() uses get_user to get the undefined
    instruction, it can be called before kprobes processes
    recursive check. This can cause an infinit recursive
    exception.
    Prohibit probing on get_user functions.
    
    Fixes: 24ba613c9d6c ("ARM kprobes: core code")
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e5f28fe3c6acd1195007132cc33f5d4fa058be32
Author: Dexuan Cui <decui@microsoft.com>
Date:   Tue May 15 19:52:50 2018 +0000

    tick/broadcast: Use for_each_cpu() specially on UP kernels
    
    commit 5596fe34495cf0f645f417eb928ef224df3e3cb4 upstream.
    
    for_each_cpu() unintuitively reports CPU0 as set independent of the actual
    cpumask content on UP kernels. This causes an unexpected PIT interrupt
    storm on a UP kernel running in an SMP virtual machine on Hyper-V, and as
    a result, the virtual machine can suffer from a strange random delay of 1~20
    minutes during boot-up, and sometimes it can hang forever.
    
    Protect if by checking whether the cpumask is empty before entering the
    for_each_cpu() loop.
    
    [ tglx: Use !IS_ENABLED(CONFIG_SMP) instead of #ifdeffery ]
    
    Signed-off-by: Dexuan Cui <decui@microsoft.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Josh Poulson <jopoulso@microsoft.com>
    Cc: "Michael Kelley (EOSG)" <Michael.H.Kelley@microsoft.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: stable@vger.kernel.org
    Cc: Rakib Mullick <rakib.mullick@gmail.com>
    Cc: Jork Loeser <Jork.Loeser@microsoft.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: KY Srinivasan <kys@microsoft.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Alexey Dobriyan <adobriyan@gmail.com>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Link: https://lkml.kernel.org/r/KL1P15301MB000678289FE55BA365B3279ABF990@KL1P15301MB0006.APCP153.PROD.OUTLOOK.COM
    Link: https://lkml.kernel.org/r/KL1P15301MB0006FA63BC22BEB64902EAA0BF930@KL1P15301MB0006.APCP153.PROD.OUTLOOK.COM
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8414385f8dd48a8e4ea1808a2776594ceca7e02c
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Sun May 13 05:04:16 2018 +0100

    ARM: 8771/1: kprobes: Prohibit kprobes on do_undefinstr
    
    commit eb0146daefdde65665b7f076fbff7b49dade95b9 upstream.
    
    Prohibit kprobes on do_undefinstr because kprobes on
    arm is implemented by undefined instruction. This means
    if we probe do_undefinstr(), it can cause infinit
    recursive exception.
    
    Fixes: 24ba613c9d6c ("ARM kprobes: core code")
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 56bd8525fd87605462f8090d25ccfdf4e1d68065
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Fri May 4 07:59:58 2018 +0200

    efi: Avoid potential crashes, fix the 'struct efi_pci_io_protocol_32' definition for mixed mode
    
    commit 0b3225ab9407f557a8e20f23f37aa7236c10a9b1 upstream.
    
    Mixed mode allows a kernel built for x86_64 to interact with 32-bit
    EFI firmware, but requires us to define all struct definitions carefully
    when it comes to pointer sizes.
    
    'struct efi_pci_io_protocol_32' currently uses a 'void *' for the
    'romimage' field, which will be interpreted as a 64-bit field
    on such kernels, potentially resulting in bogus memory references
    and subsequent crashes.
    
    Tested-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Cc: <stable@vger.kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Matt Fleming <matt@codeblueprint.co.uk>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: linux-efi@vger.kernel.org
    Link: http://lkml.kernel.org/r/20180504060003.19618-13-ard.biesheuvel@linaro.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4ef82591572d40fe0799ca204aaa685ac902ff7a
Author: Nicholas Piggin <npiggin@gmail.com>
Date:   Tue May 15 01:59:47 2018 +1000

    powerpc/powernv: Fix NVRAM sleep in invalid context when crashing
    
    commit c1d2a31397ec51f0370f6bd17b19b39152c263cb upstream.
    
    Similarly to opal_event_shutdown, opal_nvram_write can be called in
    the crash path with irqs disabled. Special case the delay to avoid
    sleeping in invalid context.
    
    Fixes: 3b8070335f75 ("powerpc/powernv: Fix OPAL NVRAM driver OPAL_BUSY loops")
    Cc: stable@vger.kernel.org # v3.2
    Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f7b727325fc50ec9288b8efdb6d49883b48c826b
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Wed May 9 14:36:09 2018 -0400

    tracing/x86/xen: Remove zero data size trace events trace_xen_mmu_flush_tlb{_all}
    
    commit 45dd9b0666a162f8e4be76096716670cf1741f0e upstream.
    
    Doing an audit of trace events, I discovered two trace events in the xen
    subsystem that use a hack to create zero data size trace events. This is not
    what trace events are for. Trace events add memory footprint overhead, and
    if all you need to do is see if a function is hit or not, simply make that
    function noinline and use function tracer filtering.
    
    Worse yet, the hack used was:
    
     __array(char, x, 0)
    
    Which creates a static string of zero in length. There's assumptions about
    such constructs in ftrace that this is a dynamic string that is nul
    terminated. This is not the case with these tracepoints and can cause
    problems in various parts of ftrace.
    
    Nuke the trace events!
    
    Link: http://lkml.kernel.org/r/20180509144605.5a220327@gandalf.local.home
    
    Cc: stable@vger.kernel.org
    Fixes: 95a7d76897c1e ("xen/mmu: Use Xen specific TLB flush instead of the generic one.")
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dc6498128bb0a978a0be41e063cb26772e4abe17
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Wed Jan 10 17:10:12 2018 +1100

    powerpc: Don't preempt_disable() in show_cpuinfo()
    
    commit 349524bc0da698ec77f2057cf4a4948eb6349265 upstream.
    
    This causes warnings from cpufreq mutex code. This is also rather
    unnecessary and ineffective. If we really want to prevent concurrent
    unplug, we could take the unplug read lock but I don't see this being
    critical.
    
    Fixes: cd77b5ce208c ("powerpc/powernv/cpufreq: Fix the frequency read by /proc/cpuinfo")
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Acked-by: Michal Suchanek <msuchanek@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8bfbeb811fa169e205169f3ae8985c3265511551
Author: Wenwen Wang <wang6495@umn.edu>
Date:   Sat May 5 13:38:03 2018 -0500

    ALSA: control: fix a redundant-copy issue
    
    commit 3f12888dfae2a48741c4caa9214885b3aaf350f9 upstream.
    
    In snd_ctl_elem_add_compat(), the fields of the struct 'data' need to be
    copied from the corresponding fields of the struct 'data32' in userspace.
    This is achieved by invoking copy_from_user() and get_user() functions. The
    problem here is that the 'type' field is copied twice. One is by
    copy_from_user() and one is by get_user(). Given that the 'type' field is
    not used between the two copies, the second copy is *completely* redundant
    and should be removed for better performance and cleanup. Also, these two
    copies can cause inconsistent data: as the struct 'data32' resides in
    userspace and a malicious userspace process can race to change the 'type'
    field between the two copies to cause inconsistent data. Depending on how
    the data is used in the future, such an inconsistency may cause potential
    security risks.
    
    For above reasons, we should take out the second copy.
    
    Signed-off-by: Wenwen Wang <wang6495@umn.edu>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4caf3f00f935ef51083b9ca8b90bc73292f73aac
Author: Federico Cuello <fedux@fedux.com.ar>
Date:   Wed May 9 00:13:38 2018 +0200

    ALSA: usb: mixer: volume quirk for CM102-A+/102S+
    
    commit 21493316a3c4598f308d5a9fa31cc74639c4caff upstream.
    
    Currently it's not possible to set volume lower than 26% (it just mutes).
    
    Also fixes this warning:
    
      Warning! Unlikely big volume range (=9472), cval->res is probably wrong.
      [13] FU [PCM Playback Volume] ch = 2, val = -9473/-1/1
    
    , and volume works fine for full range.
    
    Signed-off-by: Federico Cuello <fedux@fedux.com.ar>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 41585e8645d8d397c5c116d3ae630117c78276da
Author: Shuah Khan (Samsung OSG) <shuah@kernel.org>
Date:   Tue May 15 17:57:23 2018 -0600

    usbip: usbip_host: fix bad unlock balance during stub_probe()
    
    commit c171654caa875919be3c533d3518da8be5be966e upstream.
    
    stub_probe() calls put_busid_priv() in an error path when device isn't
    found in the busid_table. Fix it by making put_busid_priv() safe to be
    called with null struct bus_id_priv pointer.
    
    This problem happens when "usbip bind" is run without loading usbip_host
    driver and then running modprobe. The first failed bind attempt unbinds
    the device from the original driver and when usbip_host is modprobed,
    stub_probe() runs and doesn't find the device in its busid table and calls
    put_busid_priv(0 with null bus_id_priv pointer.
    
    usbip-host 3-10.2: 3-10.2 is not in match_busid table...  skip!
    
    [  367.359679] =====================================
    [  367.359681] WARNING: bad unlock balance detected!
    [  367.359683] 4.17.0-rc4+ #5 Not tainted
    [  367.359685] -------------------------------------
    [  367.359688] modprobe/2768 is trying to release lock (
    [  367.359689]
    ==================================================================
    [  367.359696] BUG: KASAN: null-ptr-deref in print_unlock_imbalance_bug+0x99/0x110
    [  367.359699] Read of size 8 at addr 0000000000000058 by task modprobe/2768
    
    [  367.359705] CPU: 4 PID: 2768 Comm: modprobe Not tainted 4.17.0-rc4+ #5
    
    Fixes: 22076557b07c ("usbip: usbip_host: fix NULL-ptr deref and use-after-free errors") in usb-linus
    Signed-off-by: Shuah Khan (Samsung OSG) <shuah@kernel.org>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d1641e51d22e7ed33ba3101c01e006120f32a653
Author: Shuah Khan (Samsung OSG) <shuah@kernel.org>
Date:   Mon May 14 20:49:58 2018 -0600

    usbip: usbip_host: fix NULL-ptr deref and use-after-free errors
    
    commit 22076557b07c12086eeb16b8ce2b0b735f7a27e7 upstream.
    
    usbip_host updates device status without holding lock from stub probe,
    disconnect and rebind code paths. When multiple requests to import a
    device are received, these unprotected code paths step all over each
    other and drive fails with NULL-ptr deref and use-after-free errors.
    
    The driver uses a table lock to protect the busid array for adding and
    deleting busids to the table. However, the probe, disconnect and rebind
    paths get the busid table entry and update the status without holding
    the busid table lock. Add a new finer grain lock to protect the busid
    entry. This new lock will be held to search and update the busid entry
    fields from get_busid_idx(), add_match_busid() and del_match_busid().
    
    match_busid_show() does the same to access the busid entry fields.
    
    get_busid_priv() changed to return the pointer to the busid entry holding
    the busid lock. stub_probe(), stub_disconnect() and stub_device_rebind()
    call put_busid_priv() to release the busid lock before returning. This
    changes fixes the unprotected code paths eliminating the race conditions
    in updating the busid entries.
    
    Reported-by: Jakub Jirasek
    Signed-off-by: Shuah Khan (Samsung OSG) <shuah@kernel.org>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d0f35e23dafa0185f979d0c70463caa658062264
Author: Alexey Khoroshilov <khoroshilov@ispras.ru>
Date:   Sat Nov 29 01:29:10 2014 +0300

    usbip: fix error handling in stub_probe()
    
    commit 3ff67445750a84de67faaf52c6e1895cb09f2c56 upstream.
    
    If usb_hub_claim_port() fails, no resources are deallocated and
    if stub_add_files() fails, port is not released.
    
    The patch fixes these issues and rearranges error handling code.
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
    Acked-by: Valentina Manea <valentina.manea.m@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d355e2700282381bd2b27f58fe35e2d5d871dd5
Author: Shuah Khan (Samsung OSG) <shuah@kernel.org>
Date:   Mon Apr 30 16:17:20 2018 -0600

    usbip: usbip_host: run rebind from exit when module is removed
    
    commit 7510df3f29d44685bab7b1918b61a8ccd57126a9 upstream.
    
    After removing usbip_host module, devices it releases are left without
    a driver. For example, when a keyboard or a mass storage device are
    bound to usbip_host when it is removed, these devices are no longer
    bound to any driver.
    
    Fix it to run device_attach() from the module exit routine to restore
    the devices to their original drivers. This includes cleanup changes
    and moving device_attach() code to a common routine to be called from
    rebind_store() and usbip_host_exit().
    
    Signed-off-by: Shuah Khan (Samsung OSG) <shuah@kernel.org>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 55c99909476209cd08379cc4b42ffcd050174ab9
Author: Shuah Khan (Samsung OSG) <shuah@kernel.org>
Date:   Mon Apr 30 16:17:19 2018 -0600

    usbip: usbip_host: delete device from busid_table after rebind
    
    commit 1e180f167d4e413afccbbb4a421b48b2de832549 upstream.
    
    Device is left in the busid_table after unbind and rebind. Rebind
    initiates usb bus scan and the original driver claims the device.
    After rescan the device should be deleted from the busid_table as
    it no longer belongs to usbip_host.
    
    Fix it to delete the device after device_attach() succeeds.
    
    Signed-off-by: Shuah Khan (Samsung OSG) <shuah@kernel.org>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 72f8ba7681d3ff1bee167dbb386ce81fbb20999a
Author: Shuah Khan <shuahkh@osg.samsung.com>
Date:   Wed Apr 11 18:13:30 2018 -0600

    usbip: usbip_host: refine probe and disconnect debug msgs to be useful
    
    commit 28b68acc4a88dcf91fd1dcf2577371dc9bf574cc upstream.
    
    Refine probe and disconnect debug msgs to be useful and say what is
    in progress.
    
    Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9535063c6fd52d42b954b68762269f6b27e26c91
Author: zhongjiang <zhongjiang@huawei.com>
Date:   Mon Jul 10 15:53:01 2017 -0700

    kernel/exit.c: avoid undefined behaviour when calling wait4()
    
    commit dd83c161fbcc5d8be637ab159c0de015cbff5ba4 upstream.
    
    wait4(-2147483648, 0x20, 0, 0xdd0000) triggers:
    UBSAN: Undefined behaviour in kernel/exit.c:1651:9
    
    The related calltrace is as follows:
    
      negation of -2147483648 cannot be represented in type 'int':
      CPU: 9 PID: 16482 Comm: zj Tainted: G    B          ---- -------   3.10.0-327.53.58.71.x86_64+ #66
      Hardware name: Huawei Technologies Co., Ltd. Tecal RH2285          /BC11BTSA              , BIOS CTSAV036 04/27/2011
      Call Trace:
        dump_stack+0x19/0x1b
        ubsan_epilogue+0xd/0x50
        __ubsan_handle_negate_overflow+0x109/0x14e
        SyS_wait4+0x1cb/0x1e0
        system_call_fastpath+0x16/0x1b
    
    Exclude the overflow to avoid the UBSAN warning.
    
    Link: http://lkml.kernel.org/r/1497264618-20212-1-git-send-email-zhongjiang@huawei.com
    Signed-off-by: zhongjiang <zhongjiang@huawei.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
    Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Cc: Xishi Qiu <qiuxishi@huawei.com>
    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 46736d5c61fe3d5d0b6b571ccdab778cf9670133
Author: Michael Kerrisk (man-pages) <mtk.manpages@gmail.com>
Date:   Tue Oct 11 13:53:43 2016 -0700

    pipe: cap initial pipe capacity according to pipe-max-size limit
    
    commit 086e774a57fba4695f14383c0818994c0b31da7c upstream.
    
    This is a patch that provides behavior that is more consistent, and
    probably less surprising to users. I consider the change optional, and
    welcome opinions about whether it should be applied.
    
    By default, pipes are created with a capacity of 64 kiB.  However,
    /proc/sys/fs/pipe-max-size may be set smaller than this value.  In this
    scenario, an unprivileged user could thus create a pipe whose initial
    capacity exceeds the limit. Therefore, it seems logical to cap the
    initial pipe capacity according to the value of pipe-max-size.
    
    The test program shown earlier in this patch series can be used to
    demonstrate the effect of the change brought about with this patch:
    
        # cat /proc/sys/fs/pipe-max-size
        1048576
        # sudo -u mtk ./test_F_SETPIPE_SZ 1
        Initial pipe capacity: 65536
        # echo 10000 > /proc/sys/fs/pipe-max-size
        # cat /proc/sys/fs/pipe-max-size
        16384
        # sudo -u mtk ./test_F_SETPIPE_SZ 1
        Initial pipe capacity: 16384
        # ./test_F_SETPIPE_SZ 1
        Initial pipe capacity: 65536
    
    The last two executions of 'test_F_SETPIPE_SZ' show that pipe-max-size
    caps the initial allocation for a new pipe for unprivileged users, but
    not for privileged users.
    
    Link: http://lkml.kernel.org/r/31dc7064-2a17-9c5b-1df1-4e3012ee992c@gmail.com
    Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
    Reviewed-by: Vegard Nossum <vegard.nossum@oracle.com>
    Cc: Willy Tarreau <w@1wt.eu>
    Cc: <socketpair@gmail.com>
    Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Cc: Jens Axboe <axboe@fb.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8ef1995c4be2af18c7b1ea84e162746e1cb5d0f9
Author: James Chapman <jchapman@katalix.com>
Date:   Wed Jan 3 22:48:05 2018 +0000

    l2tp: revert "l2tp: fix missing print session offset info"
    
    commit de3b58bc359a861d5132300f53f95e83f71954b3 upstream.
    
    Revert commit 820da5357572 ("l2tp: fix missing print session offset
    info").  The peer_offset parameter is removed.
    
    Signed-off-by: James Chapman <jchapman@katalix.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Guillaume Nault <g.nault@alphalink.fr>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 50a8b06f3350524b47e4182b8af60c75620d022c
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu May 17 11:48:48 2018 +0200

    Revert "ARM: dts: imx6qdl-wandboard: Fix audio channel swap"
    
    This reverts commit 2ebf343cbed76773563223761586fd5edcd0dc61 which was
    commit 79935915300c5eb88a0e94fa9148a7505c14a02a upstream.
    
    As Ben points out:
            This depends on:
    
            commit 570c70a60f53ca737ead4e5966c446bf0d39fac9
            Author: Fabio Estevam <fabio.estevam@nxp.com>
            Date:   Wed Apr 5 11:32:34 2017 -0300
    
                ASoC: sgtl5000: Allow LRCLK pad drive strength to be changed
    
    which did not show up until 4.13, so this makes no sense to have in this
    stable branch.
    
    Reported-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Cc: Fabio Estevam <fabio.estevam@nxp.com>
    Cc: Shawn Guo <shawnguo@kernel.org>
    Cc: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a92d8572a165353bbc87e09ced83ae0c989e04a2
Author: Vasily Averin <vvs@virtuozzo.com>
Date:   Thu Nov 2 13:03:42 2017 +0300

    lockd: lost rollback of set_grace_period() in lockd_down_net()
    
    commit 3a2b19d1ee5633f76ae8a88da7bc039a5d1732aa upstream.
    
    Commit efda760fe95ea ("lockd: fix lockd shutdown race") is incorrect,
    it removes lockd_manager and disarm grace_period_end for init_net only.
    
    If nfsd was started from another net namespace lockd_up_net() calls
    set_grace_period() that adds lockd_manager into per-netns list
    and queues grace_period_end delayed work.
    
    These action should be reverted in lockd_down_net().
    Otherwise it can lead to double list_add on after restart nfsd in netns,
    and to use-after-free if non-disarmed delayed work will be executed after netns destroy.
    
    Fixes: efda760fe95e ("lockd: fix lockd shutdown race")
    Cc: stable@vger.kernel.org
    Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5adf47be56e58629c50c51023306217c4e0559b0
Author: Bjørn Mork <bjorn@mork.no>
Date:   Wed May 2 22:22:54 2018 +0200

    qmi_wwan: do not steal interfaces from class drivers
    
    [ Upstream commit 5697db4a696c41601a1d15c1922150b4dbf5726c ]
    
    The USB_DEVICE_INTERFACE_NUMBER matching macro assumes that
    the { vendorid, productid, interfacenumber } set uniquely
    identifies one specific function.  This has proven to fail
    for some configurable devices. One example is the Quectel
    EM06/EP06 where the same interface number can be either
    QMI or MBIM, without the device ID changing either.
    
    Fix by requiring the vendor-specific class for interface number
    based matching.  Functions of other classes can and should use
    class based matching instead.
    
    Fixes: 03304bcb5ec4 ("net: qmi_wwan: use fixed interface number matching")
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6723603d0729f3cde6442de85d85d593fb951bd0
Author: Xin Long <lucien.xin@gmail.com>
Date:   Sat May 5 14:59:47 2018 +0800

    sctp: delay the authentication for the duplicated cookie-echo chunk
    
    [ Upstream commit 59d8d4434f429b4fa8a346fd889058bda427a837 ]
    
    Now sctp only delays the authentication for the normal cookie-echo
    chunk by setting chunk->auth_chunk in sctp_endpoint_bh_rcv(). But
    for the duplicated one with auth, in sctp_assoc_bh_rcv(), it does
    authentication first based on the old asoc, which will definitely
    fail due to the different auth info in the old asoc.
    
    The duplicated cookie-echo chunk will create a new asoc with the
    auth info from this chunk, and the authentication should also be
    done with the new asoc's auth info for all of the collision 'A',
    'B' and 'D'. Otherwise, the duplicated cookie-echo chunk with auth
    will never pass the authentication and create the new connection.
    
    This issue exists since very beginning, and this fix is to make
    sctp_assoc_bh_rcv() follow the way sctp_endpoint_bh_rcv() does
    for the normal cookie-echo chunk to delay the authentication.
    
    While at it, remove the unused params from sctp_sf_authenticate()
    and define sctp_auth_chunk_verify() used for all the places that
    do the delayed authentication.
    
    v1->v2:
      fix the typo in changelog as Marcelo noticed.
    
    Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c0b1359489cf5def67c15233234c855d035e952b
Author: Xin Long <lucien.xin@gmail.com>
Date:   Wed May 2 13:45:12 2018 +0800

    sctp: fix the issue that the cookie-ack with auth can't get processed
    
    [ Upstream commit ce402f044e4e432c296f90eaabb8dbe8f3624391 ]
    
    When auth is enabled for cookie-ack chunk, in sctp_inq_pop, sctp
    processes auth chunk first, then continues to the next chunk in
    this packet if chunk_end + chunk_hdr size < skb_tail_pointer().
    Otherwise, it will go to the next packet or discard this chunk.
    
    However, it missed the fact that cookie-ack chunk's size is equal
    to chunk_hdr size, which couldn't match that check, and thus this
    chunk would not get processed.
    
    This patch fixes it by changing the check to chunk_end + chunk_hdr
    size <= skb_tail_pointer().
    
    Fixes: 26b87c788100 ("net: sctp: fix remote memory pressure from excessive queueing")
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7081fa7b4618b65d007299e7ae1dd8646d65d21d
Author: Yuchung Cheng <ycheng@google.com>
Date:   Wed Apr 25 11:33:08 2018 -0700

    tcp: ignore Fast Open on repair mode
    
    [ Upstream commit 16ae6aa1705299789f71fdea59bfb119c1fbd9c0 ]
    
    The TCP repair sequence of operation is to first set the socket in
    repair mode, then inject the TCP stats into the socket with repair
    socket options, then call connect() to re-activate the socket. The
    connect syscall simply returns and set state to ESTABLISHED
    mode. As a result Fast Open is meaningless for TCP repair.
    
    However allowing sendto() system call with MSG_FASTOPEN flag half-way
    during the repair operation could unexpectedly cause data to be
    sent, before the operation finishes changing the internal TCP stats
    (e.g. MSS).  This in turn triggers TCP warnings on inconsistent
    packet accounting.
    
    The fix is to simply disallow Fast Open operation once the socket
    is in the repair mode.
    
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Yuchung Cheng <ycheng@google.com>
    Reviewed-by: Neal Cardwell <ncardwell@google.com>
    Reviewed-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 954db9a11570d4f796833137557d10d4696f3f1d
Author: Debabrata Banerjee <dbanerje@akamai.com>
Date:   Wed May 9 19:32:10 2018 -0400

    bonding: do not allow rlb updates to invalid mac
    
    [ Upstream commit 4fa8667ca3989ce14cf66301fa251544fbddbdd0 ]
    
    Make sure multicast, broadcast, and zero mac's cannot be the output of rlb
    updates, which should all be directed arps. Receive load balancing will be
    collapsed if any of these happen, as the switch will broadcast.
    
    Signed-off-by: Debabrata Banerjee <dbanerje@akamai.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3293c85bb2ad73644430228f6632e128f3903d8e
Author: Michael Chan <michael.chan@broadcom.com>
Date:   Thu May 3 20:04:27 2018 -0400

    tg3: Fix vunmap() BUG_ON() triggered from tg3_free_consistent().
    
    [ Upstream commit d89a2adb8bfe6f8949ff389acdb9fa298b6e8e12 ]
    
    tg3_free_consistent() calls dma_free_coherent() to free tp->hw_stats
    under spinlock and can trigger BUG_ON() in vunmap() because vunmap()
    may sleep.  Fix it by removing the spinlock and relying on the
    TG3_FLAG_INIT_COMPLETE flag to prevent race conditions between
    tg3_get_stats64() and tg3_free_consistent().  TG3_FLAG_INIT_COMPLETE
    is always cleared under tp->lock before tg3_free_consistent()
    and therefore tg3_get_stats64() can safely access tp->hw_stats
    under tp->lock if TG3_FLAG_INIT_COMPLETE is set.
    
    Fixes: f5992b72ebe0 ("tg3: Fix race condition in tg3_get_stats64().")
    Reported-by: Zumeng Chen <zumeng.chen@gmail.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit defbbf4c87a4e497037152d640eca5aa86a9d367
Author: Xin Long <lucien.xin@gmail.com>
Date:   Wed May 2 13:39:46 2018 +0800

    sctp: use the old asoc when making the cookie-ack chunk in dupcook_d
    
    [ Upstream commit 46e16d4b956867013e0bbd7f2bad206f4aa55752 ]
    
    When processing a duplicate cookie-echo chunk, for case 'D', sctp will
    not process the param from this chunk. It means old asoc has nothing
    to be updated, and the new temp asoc doesn't have the complete info.
    
    So there's no reason to use the new asoc when creating the cookie-ack
    chunk. Otherwise, like when auth is enabled for cookie-ack, the chunk
    can not be set with auth, and it will definitely be dropped by peer.
    
    This issue is there since very beginning, and we fix it by using the
    old asoc instead.
    
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2e7d9d72b9482f2e563b088a791390153569cc43
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Mon May 7 21:11:21 2018 +0200

    r8169: fix powering up RTL8168h
    
    [ Upstream commit 3148dedfe79e422f448a10250d3e2cdf8b7ee617 ]
    
    Since commit a92a08499b1f "r8169: improve runtime pm in general and
    suspend unused ports" interfaces w/o link are runtime-suspended after
    10s. On systems where drivers take longer to load this can lead to the
    situation that the interface is runtime-suspended already when it's
    initially brought up.
    This shouldn't be a problem because rtl_open() resumes MAC/PHY.
    However with at least one chip version the interface doesn't properly
    come up, as reported here:
    https://bugzilla.kernel.org/show_bug.cgi?id=199549
    
    The vendor driver uses a delay to give certain chip versions some
    time to resume before starting the PHY configuration. So let's do
    the same. I don't know which chip versions may be affected,
    therefore apply this delay always.
    
    This patch was reported to fix the issue for RTL8168h.
    I was able to reproduce the issue on an Asus H310I-Plus which also
    uses a RTL8168h. Also in my case the patch fixed the issue.
    
    Reported-by: Slava Kardakov <ojab@ojab.ru>
    Tested-by: Slava Kardakov <ojab@ojab.ru>
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cd38252dad4444f122f0b26c80127c5ffe70bb84
Author: Lance Richardson <lance.richardson.net@gmail.com>
Date:   Wed Apr 25 10:21:54 2018 -0400

    net: support compat 64-bit time in {s,g}etsockopt
    
    [ Upstream commit 988bf7243e03ef69238381594e0334a79cef74a6 ]
    
    For the x32 ABI, struct timeval has two 64-bit fields. However
    the kernel currently interprets the user-space values used for
    the SO_RCVTIMEO and SO_SNDTIMEO socket options as having a pair
    of 32-bit fields.
    
    When the seconds portion of the requested timeout is less than 2**32,
    the seconds portion of the effective timeout is correct but the
    microseconds portion is zero.  When the seconds portion of the
    requested timeout is zero and the microseconds portion is non-zero,
    the kernel interprets the timeout as zero (never timeout).
    
    Fix by using 64-bit time for SO_RCVTIMEO/SO_SNDTIMEO as required
    for the ABI.
    
    The code included below demonstrates the problem.
    
    Results before patch:
        $ gcc -m64 -Wall -O2 -o socktmo socktmo.c && ./socktmo
        recv time: 2.008181 seconds
        send time: 2.015985 seconds
    
        $ gcc -m32 -Wall -O2 -o socktmo socktmo.c && ./socktmo
        recv time: 2.016763 seconds
        send time: 2.016062 seconds
    
        $ gcc -mx32 -Wall -O2 -o socktmo socktmo.c && ./socktmo
        recv time: 1.007239 seconds
        send time: 1.023890 seconds
    
    Results after patch:
        $ gcc -m64 -O2 -Wall -o socktmo socktmo.c && ./socktmo
        recv time: 2.010062 seconds
        send time: 2.015836 seconds
    
        $ gcc -m32 -O2 -Wall -o socktmo socktmo.c && ./socktmo
        recv time: 2.013974 seconds
        send time: 2.015981 seconds
    
        $ gcc -mx32 -O2 -Wall -o socktmo socktmo.c && ./socktmo
        recv time: 2.030257 seconds
        send time: 2.013383 seconds
    
     #include <stdio.h>
     #include <stdlib.h>
     #include <sys/socket.h>
     #include <sys/types.h>
     #include <sys/time.h>
    
     void checkrc(char *str, int rc)
     {
             if (rc >= 0)
                     return;
    
             perror(str);
             exit(1);
     }
    
     static char buf[1024];
     int main(int argc, char **argv)
     {
             int rc;
             int socks[2];
             struct timeval tv;
             struct timeval start, end, delta;
    
             rc = socketpair(AF_UNIX, SOCK_STREAM, 0, socks);
             checkrc("socketpair", rc);
    
             /* set timeout to 1.999999 seconds */
             tv.tv_sec = 1;
             tv.tv_usec = 999999;
             rc = setsockopt(socks[0], SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof tv);
             rc = setsockopt(socks[0], SOL_SOCKET, SO_SNDTIMEO, &tv, sizeof tv);
             checkrc("setsockopt", rc);
    
             /* measure actual receive timeout */
             gettimeofday(&start, NULL);
             rc = recv(socks[0], buf, sizeof buf, 0);
             gettimeofday(&end, NULL);
             timersub(&end, &start, &delta);
    
             printf("recv time: %ld.%06ld seconds\n",
                    (long)delta.tv_sec, (long)delta.tv_usec);
    
             /* fill send buffer */
             do {
                     rc = send(socks[0], buf, sizeof buf, 0);
             } while (rc > 0);
    
             /* measure actual send timeout */
             gettimeofday(&start, NULL);
             rc = send(socks[0], buf, sizeof buf, 0);
             gettimeofday(&end, NULL);
             timersub(&end, &start, &delta);
    
             printf("send time: %ld.%06ld seconds\n",
                    (long)delta.tv_sec, (long)delta.tv_usec);
             exit(0);
     }
    
    Fixes: 515c7af85ed9 ("x32: Use compat shims for {g,s}etsockopt")
    Reported-by: Gopal RajagopalSai <gopalsr83@gmail.com>
    Signed-off-by: Lance Richardson <lance.richardson.net@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8beff8dcb4e743645f9b5a1aed8fa09ff0f48cea
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed May 2 10:03:30 2018 -0700

    net_sched: fq: take care of throttled flows before reuse
    
    [ Upstream commit 7df40c2673a1307c3260aab6f9d4b9bf97ca8fd7 ]
    
    Normally, a socket can not be freed/reused unless all its TX packets
    left qdisc and were TX-completed. However connect(AF_UNSPEC) allows
    this to happen.
    
    With commit fc59d5bdf1e3 ("pkt_sched: fq: clear time_next_packet for
    reused flows") we cleared f->time_next_packet but took no special
    action if the flow was still in the throttled rb-tree.
    
    Since f->time_next_packet is the key used in the rb-tree searches,
    blindly clearing it might break rb-tree integrity. We need to make
    sure the flow is no longer in the rb-tree to avoid this problem.
    
    Fixes: fc59d5bdf1e3 ("pkt_sched: fq: clear time_next_packet for reused flows")
    Signed-off-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 0a754eaa35a98ce108d7675819b3b58d5882fc39
Author: Moshe Shemesh <moshe@mellanox.com>
Date:   Wed May 9 18:35:13 2018 +0300

    net/mlx4_en: Verify coalescing parameters are in range
    
    [ Upstream commit 6ad4e91c6d796b38a7f0e724db1de28eeb122bad ]
    
    Add check of coalescing parameters received through ethtool are within
    range of values supported by the HW.
    Driver gets the coalescing rx/tx-usecs and rx/tx-frames as set by the
    users through ethtool. The ethtool support up to 32 bit value for each.
    However, mlx4 modify cq limits the coalescing time parameter and
    coalescing frames parameters to 16 bits.
    Return out of range error if user tries to set these parameters to
    higher values.
    Change type of sample-interval and adaptive_rx_coal parameters in mlx4
    driver to u32 as the ethtool holds them as u32 and these parameters are
    not limited due to mlx4 HW.
    
    Fixes: c27a02cd94d6 ('mlx4_en: Add driver for Mellanox ConnectX 10GbE NIC')
    Signed-off-by: Moshe Shemesh <moshe@mellanox.com>
    Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ac9e8fa386f5e501ffdb3cb29e7ca9e612e1012
Author: Rob Taglang <rob@taglang.io>
Date:   Thu May 3 17:13:06 2018 -0400

    net: ethernet: sun: niu set correct packet size in skb
    
    [ Upstream commit 14224923c3600bae2ac4dcae3bf0c3d4dc2812be ]
    
    Currently, skb->len and skb->data_len are set to the page size, not
    the packet size. This causes the frame check sequence to not be
    located at the "end" of the packet resulting in ethernet frame check
    errors. The driver does work currently, but stricter kernel facing
    networking solutions like OpenVSwitch will drop these packets as
    invalid.
    
    These changes set the packet size correctly so that these errors no
    longer occur. The length does not include the frame check sequence, so
    that subtraction was removed.
    
    Tested on Oracle/SUN Multithreaded 10-Gigabit Ethernet Network
    Controller [108e:abcd] and validated in wireshark.
    
    Signed-off-by: Rob Taglang <rob@taglang.io>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 018c802a6f489bb5b5f9a4b579490c21dbb5cc74
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon May 7 09:02:25 2018 -0700

    llc: better deal with too small mtu
    
    [ Upstream commit 2c5d5b13c6eb79f5677e206b8aad59b3a2097f60 ]
    
    syzbot loves to set very small mtu on devices, since it brings joy.
    We must make llc_ui_sendmsg() fool proof.
    
    usercopy: Kernel memory overwrite attempt detected to wrapped address (offset 0, size 18446612139802320068)!
    
    kernel BUG at mm/usercopy.c:100!
    invalid opcode: 0000 [#1] SMP KASAN
    Dumping ftrace buffer:
       (ftrace buffer empty)
    Modules linked in:
    CPU: 0 PID: 17464 Comm: syz-executor1 Not tainted 4.17.0-rc3+ #36
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    RIP: 0010:usercopy_abort+0xbb/0xbd mm/usercopy.c:88
    RSP: 0018:ffff8801868bf800 EFLAGS: 00010282
    RAX: 000000000000006c RBX: ffffffff87d2fb00 RCX: 0000000000000000
    RDX: 000000000000006c RSI: ffffffff81610731 RDI: ffffed0030d17ef6
    RBP: ffff8801868bf858 R08: ffff88018daa4200 R09: ffffed003b5c4fb0
    R10: ffffed003b5c4fb0 R11: ffff8801dae27d87 R12: ffffffff87d2f8e0
    R13: ffffffff87d2f7a0 R14: ffffffff87d2f7a0 R15: ffffffff87d2f7a0
    FS:  00007f56a14ac700(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000001b2bc21000 CR3: 00000001abeb1000 CR4: 00000000001426f0
    DR0: 0000000020000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000030602
    Call Trace:
     check_bogus_address mm/usercopy.c:153 [inline]
     __check_object_size+0x5d9/0x5d9 mm/usercopy.c:256
     check_object_size include/linux/thread_info.h:108 [inline]
     check_copy_size include/linux/thread_info.h:139 [inline]
     copy_from_iter_full include/linux/uio.h:121 [inline]
     memcpy_from_msg include/linux/skbuff.h:3305 [inline]
     llc_ui_sendmsg+0x4b1/0x1530 net/llc/af_llc.c:941
     sock_sendmsg_nosec net/socket.c:629 [inline]
     sock_sendmsg+0xd5/0x120 net/socket.c:639
     __sys_sendto+0x3d7/0x670 net/socket.c:1789
     __do_sys_sendto net/socket.c:1801 [inline]
     __se_sys_sendto net/socket.c:1797 [inline]
     __x64_sys_sendto+0xe1/0x1a0 net/socket.c:1797
     do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    RIP: 0033:0x455979
    RSP: 002b:00007f56a14abc68 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
    RAX: ffffffffffffffda RBX: 00007f56a14ac6d4 RCX: 0000000000455979
    RDX: 0000000000000000 RSI: 0000000020000000 RDI: 0000000000000018
    RBP: 000000000072bea0 R08: 00000000200012c0 R09: 0000000000000010
    R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
    R13: 0000000000000548 R14: 00000000006fbf60 R15: 0000000000000000
    Code: 55 c0 e8 c0 55 bb ff ff 75 c8 48 8b 55 c0 4d 89 f9 ff 75 d0 4d 89 e8 48 89 d9 4c 89 e6 41 56 48 c7 c7 80 fa d2 87 e8 a0 0b a3 ff <0f> 0b e8 95 55 bb ff e8 c0 a8 f7 ff 8b 95 14 ff ff ff 4d 89 e8
    RIP: usercopy_abort+0xbb/0xbd mm/usercopy.c:88 RSP: ffff8801868bf800
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fb1048128f9db7604a2163e237f8110ddef98cac
Author: Andrey Ignatov <rdna@fb.com>
Date:   Thu May 10 10:59:34 2018 -0700

    ipv4: fix memory leaks in udp_sendmsg, ping_v4_sendmsg
    
    [ Upstream commit 1b97013bfb11d66f041de691de6f0fec748ce016 ]
    
    Fix more memory leaks in ip_cmsg_send() callers. Part of them were fixed
    earlier in 919483096bfe.
    
    * udp_sendmsg one was there since the beginning when linux sources were
      first added to git;
    * ping_v4_sendmsg one was copy/pasted in c319b4d76b9e.
    
    Whenever return happens in udp_sendmsg() or ping_v4_sendmsg() IP options
    have to be freed if they were allocated previously.
    
    Add label so that future callers (if any) can use it instead of kfree()
    before return that is easy to forget.
    
    Fixes: c319b4d76b9e (net: ipv4: add IPPROTO_ICMP socket kind)
    Signed-off-by: Andrey Ignatov <rdna@fb.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7eaa949984a07437bbc3d5c438ff66d72dd9e118
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu May 3 09:39:20 2018 -0700

    dccp: fix tasklet usage
    
    [ Upstream commit a8d7aa17bbc970971ccdf71988ea19230ab368b1 ]
    
    syzbot reported a crash in tasklet_action_common() caused by dccp.
    
    dccp needs to make sure socket wont disappear before tasklet handler
    has completed.
    
    This patch takes a reference on the socket when arming the tasklet,
    and moves the sock_put() from dccp_write_xmit_timer() to dccp_write_xmitlet()
    
    kernel BUG at kernel/softirq.c:514!
    invalid opcode: 0000 [#1] SMP KASAN
    Dumping ftrace buffer:
       (ftrace buffer empty)
    Modules linked in:
    CPU: 1 PID: 17 Comm: ksoftirqd/1 Not tainted 4.17.0-rc3+ #30
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    RIP: 0010:tasklet_action_common.isra.19+0x6db/0x700 kernel/softirq.c:515
    RSP: 0018:ffff8801d9b3faf8 EFLAGS: 00010246
    dccp_close: ABORT with 65423 bytes unread
    RAX: 1ffff1003b367f6b RBX: ffff8801daf1f3f0 RCX: 0000000000000000
    RDX: ffff8801cf895498 RSI: 0000000000000004 RDI: 0000000000000000
    RBP: ffff8801d9b3fc40 R08: ffffed0039f12a95 R09: ffffed0039f12a94
    dccp_close: ABORT with 65423 bytes unread
    R10: ffffed0039f12a94 R11: ffff8801cf8954a3 R12: 0000000000000000
    R13: ffff8801d9b3fc18 R14: dffffc0000000000 R15: ffff8801cf895490
    FS:  0000000000000000(0000) GS:ffff8801daf00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000001b2bc28000 CR3: 00000001a08a9000 CR4: 00000000001406e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     tasklet_action+0x1d/0x20 kernel/softirq.c:533
     __do_softirq+0x2e0/0xaf5 kernel/softirq.c:285
    dccp_close: ABORT with 65423 bytes unread
     run_ksoftirqd+0x86/0x100 kernel/softirq.c:646
     smpboot_thread_fn+0x417/0x870 kernel/smpboot.c:164
     kthread+0x345/0x410 kernel/kthread.c:238
     ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
    Code: 48 8b 85 e8 fe ff ff 48 8b 95 f0 fe ff ff e9 94 fb ff ff 48 89 95 f0 fe ff ff e8 81 53 6e 00 48 8b 95 f0 fe ff ff e9 62 fb ff ff <0f> 0b 48 89 cf 48 89 8d e8 fe ff ff e8 64 53 6e 00 48 8b 8d e8
    RIP: tasklet_action_common.isra.19+0x6db/0x700 kernel/softirq.c:515 RSP: ffff8801d9b3faf8
    
    Fixes: dc841e30eaea ("dccp: Extend CCID packet dequeueing interface")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Cc: Gerrit Renker <gerrit@erg.abdn.ac.uk>
    Cc: dccp@vger.kernel.org
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 32037ab332f95a914923d7017377815e5d1f6433
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Fri Apr 27 20:59:24 2018 +0800

    bridge: check iface upper dev when setting master via ioctl
    
    [ Upstream commit e8238fc2bd7b4c3c7554fa2df067e796610212fc ]
    
    When we set a bond slave's master to bridge via ioctl, we only check
    the IFF_BRIDGE_PORT flag. Although we will find the slave's real master
    at netdev_master_upper_dev_link() later, it already does some settings
    and allocates some resources. It would be better to return as early
    as possible.
    
    v1 -> v2:
    use netdev_master_upper_dev_get() instead of netdev_has_any_upper_dev()
    to check if we have a master, because not all upper devs are masters,
    e.g. vlan device.
    
    Reported-by: syzbot+de73361ee4971b6e6f75@syzkaller.appspotmail.com
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Acked-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 683e95207e1aea6791a0d7242f5b7e71d52cc5d0
Author: Ingo Molnar <mingo@elte.hu>
Date:   Wed May 2 13:30:57 2018 +0200

    8139too: Use disable_irq_nosync() in rtl8139_poll_controller()
    
    [ Upstream commit af3e0fcf78879f718c5f73df0814951bd7057d34 ]
    
    Use disable_irq_nosync() instead of disable_irq() as this might be
    called in atomic context with netpoll.
    
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>