commit 0b047cbc44ae7d0cea41a99cd7ec1f009360a605
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Nov 10 07:48:36 2018 -0800

    Linux 4.14.80

commit 3a2b1d50bb294b7d5c31308ae4c04a87b6c82176
Author: Christophe Leroy <christophe.leroy@c-s.fr>
Date:   Tue Jan 16 10:33:05 2018 +0100

    net: fs_enet: do not call phy_stop() in interrupts
    
    [ Upstream commit f8b39039cbf2a15f2b8c9f081e1cbd5dee00aaf5 ]
    
    In case of TX timeout, fs_timeout() calls phy_stop(), which
    triggers the following BUG_ON() as we are in interrupt.
    
    [92708.199889] kernel BUG at drivers/net/phy/mdio_bus.c:482!
    [92708.204985] Oops: Exception in kernel mode, sig: 5 [#1]
    [92708.210119] PREEMPT
    [92708.212107] CMPC885
    [92708.214216] CPU: 0 PID: 3 Comm: ksoftirqd/0 Tainted: G        W       4.9.61 #39
    [92708.223227] task: c60f0a40 task.stack: c6104000
    [92708.227697] NIP: c02a84bc LR: c02a947c CTR: c02a93d8
    [92708.232614] REGS: c6105c70 TRAP: 0700   Tainted: G        W        (4.9.61)
    [92708.241193] MSR: 00021032 <ME,IR,DR,RI>[92708.244818]   CR: 24000822  XER: 20000000
    [92708.248767]
    GPR00: c02a947c c6105d20 c60f0a40 c62b4c00 00000005 0000001f c069aad8 0001a688
    GPR08: 00000007 00000100 c02a93d8 00000000 000005fc 00000000 c6213240 c06338e4
    GPR16: 00000001 c06330d4 c0633094 00000000 c0680000 c6104000 c6104000 00000000
    GPR24: 00000200 00000000 ffffffff 00000004 00000078 00009032 00000000 c62b4c00
    NIP [c02a84bc] mdiobus_read+0x20/0x74
    [92708.281517] LR [c02a947c] kszphy_config_intr+0xa4/0xc4
    [92708.286547] Call Trace:
    [92708.288980] [c6105d20] [c6104000] 0xc6104000 (unreliable)
    [92708.294339] [c6105d40] [c02a947c] kszphy_config_intr+0xa4/0xc4
    [92708.300098] [c6105d50] [c02a5330] phy_stop+0x60/0x9c
    [92708.305007] [c6105d60] [c02c84d0] fs_timeout+0xdc/0x110
    [92708.310197] [c6105d80] [c035cd48] dev_watchdog+0x268/0x2a0
    [92708.315593] [c6105db0] [c0060288] call_timer_fn+0x34/0x17c
    [92708.321014] [c6105dd0] [c00605f0] run_timer_softirq+0x21c/0x2e4
    [92708.326887] [c6105e50] [c001e19c] __do_softirq+0xf4/0x2f4
    [92708.332207] [c6105eb0] [c001e3c8] run_ksoftirqd+0x2c/0x40
    [92708.337560] [c6105ec0] [c003b420] smpboot_thread_fn+0x1f0/0x258
    [92708.343405] [c6105ef0] [c003745c] kthread+0xbc/0xd0
    [92708.348217] [c6105f40] [c000c400] ret_from_kernel_thread+0x5c/0x64
    [92708.354275] Instruction dump:
    [92708.357207] 7c0803a6 bbc10018 38210020 4e800020 7c0802a6 9421ffe0 54290024 bfc10018
    [92708.364865] 90010024 7c7f1b78 81290008 552902ee <0f090000> 3bc3002c 7fc3f378 90810008
    [92708.372711] ---[ end trace 42b05441616fafd7 ]---
    
    This patch moves fs_timeout() actions into an async worker.
    
    Fixes: commit 48257c4f168e5 ("Add fs_enet ethernet network driver, for several embedded platforms")
    Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ce4454ff2b2de585f059b011dc1b77205f76d607
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date:   Tue Oct 16 22:25:25 2018 +0200

    x86/fpu: Fix i486 + no387 boot crash by only saving FPU registers on context switch if there is an FPU
    
    commit 2224d616528194b02424c91c2ee254b3d29942c3 upstream.
    
    Booting an i486 with "no387 nofxsr" ends with with the following crash:
    
       math_emulate: 0060:c101987d
       Kernel panic - not syncing: Math emulation needed in kernel
    
    on the first context switch in user land.
    
    The reason is that copy_fpregs_to_fpstate() tries FNSAVE which does not work
    as the FPU is turned off.
    
    This bug was introduced in:
    
      f1c8cd0176078 ("x86/fpu: Change fpu->fpregs_active users to fpu->fpstate_active")
    
    Add a check for X86_FEATURE_FPU before trying to save FPU registers (we
    have such a check in switch_fpu_finish() already).
    
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Reviewed-by: Andy Lutomirski <luto@kernel.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Fixes: f1c8cd0176078 ("x86/fpu: Change fpu->fpregs_active users to fpu->fpstate_active")
    Link: http://lkml.kernel.org/r/20181016202525.29437-4-bigeasy@linutronix.de
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 70931375b112460ab15d601a1e89c6f2d0701012
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Fri Oct 12 17:53:12 2018 -0700

    x86/time: Correct the attribute on jiffies' definition
    
    commit 53c13ba8ed39e89f21a0b98f4c8a241bb44e483d upstream.
    
    Clang warns that the declaration of jiffies in include/linux/jiffies.h
    doesn't match the definition in arch/x86/time/kernel.c:
    
    arch/x86/kernel/time.c:29:42: warning: section does not match previous declaration [-Wsection]
    __visible volatile unsigned long jiffies __cacheline_aligned = INITIAL_JIFFIES;
                                             ^
    ./include/linux/cache.h:49:4: note: expanded from macro '__cacheline_aligned'
                     __section__(".data..cacheline_aligned")))
                     ^
    ./include/linux/jiffies.h:81:31: note: previous attribute is here
    extern unsigned long volatile __cacheline_aligned_in_smp __jiffy_arch_data jiffies;
                                  ^
    ./arch/x86/include/asm/cache.h:20:2: note: expanded from macro '__cacheline_aligned_in_smp'
            __page_aligned_data
            ^
    ./include/linux/linkage.h:39:29: note: expanded from macro '__page_aligned_data'
    #define __page_aligned_data     __section(.data..page_aligned) __aligned(PAGE_SIZE)
                                    ^
    ./include/linux/compiler_attributes.h:233:56: note: expanded from macro '__section'
    #define __section(S)                    __attribute__((__section__(#S)))
                                                           ^
    1 warning generated.
    
    The declaration was changed in commit 7c30f352c852 ("jiffies.h: declare
    jiffies and jiffies_64 with ____cacheline_aligned_in_smp") but wasn't
    updated here. Make them match so Clang no longer warns.
    
    Fixes: 7c30f352c852 ("jiffies.h: declare jiffies and jiffies_64 with ____cacheline_aligned_in_smp")
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Nick Desaulniers <ndesaulniers@google.com>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20181013005311.28617-1-natechancellor@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 577bfbe31fa9da8c8ed1c045a9be8d3cc21f1664
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Thu Oct 11 12:38:27 2018 +0200

    x86/percpu: Fix this_cpu_read()
    
    commit b59167ac7bafd804c91e49ad53c6d33a7394d4c8 upstream.
    
    Eric reported that a sequence count loop using this_cpu_read() got
    optimized out. This is wrong, this_cpu_read() must imply READ_ONCE()
    because the interface is IRQ-safe, therefore an interrupt can have
    changed the per-cpu value.
    
    Fixes: 7c3576d261ce ("[PATCH] i386: Convert PDA into the percpu section")
    Reported-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Cc: hpa@zytor.com
    Cc: eric.dumazet@gmail.com
    Cc: bp@alien8.de
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20181011104019.748208519@infradead.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f6273f584fd74bcee9aa16db3f0e2fbcae48e86
Author: Zhimin Gu <kookoo.gu@intel.com>
Date:   Fri Sep 21 14:26:24 2018 +0800

    x86, hibernate: Fix nosave_regions setup for hibernation
    
    commit cc55f7537db6af371e9c1c6a71161ee40f918824 upstream.
    
    On 32bit systems, nosave_regions(non RAM areas) located between
    max_low_pfn and max_pfn are not excluded from hibernation snapshot
    currently, which may result in a machine check exception when
    trying to access these unsafe regions during hibernation:
    
    [  612.800453] Disabling lock debugging due to kernel taint
    [  612.805786] mce: [Hardware Error]: CPU 0: Machine Check Exception: 5 Bank 6: fe00000000801136
    [  612.814344] mce: [Hardware Error]: RIP !INEXACT! 60:<00000000d90be566> {swsusp_save+0x436/0x560}
    [  612.823167] mce: [Hardware Error]: TSC 1f5939fe276 ADDR dd000000 MISC 30e0000086
    [  612.830677] mce: [Hardware Error]: PROCESSOR 0:306c3 TIME 1529487426 SOCKET 0 APIC 0 microcode 24
    [  612.839581] mce: [Hardware Error]: Run the above through 'mcelog --ascii'
    [  612.846394] mce: [Hardware Error]: Machine check: Processor context corrupt
    [  612.853380] Kernel panic - not syncing: Fatal machine check
    [  612.858978] Kernel Offset: 0x18000000 from 0xc1000000 (relocation range: 0xc0000000-0xf7ffdfff)
    
    This is because on 32bit systems, pages above max_low_pfn are regarded
    as high memeory, and accessing unsafe pages might cause expected MCE.
    On the problematic 32bit system, there are reserved memory above low
    memory, which triggered the MCE:
    
    e820 memory mapping:
    [    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009d7ff] usable
    [    0.000000] BIOS-e820: [mem 0x000000000009d800-0x000000000009ffff] reserved
    [    0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
    [    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000d160cfff] usable
    [    0.000000] BIOS-e820: [mem 0x00000000d160d000-0x00000000d1613fff] ACPI NVS
    [    0.000000] BIOS-e820: [mem 0x00000000d1614000-0x00000000d1a44fff] usable
    [    0.000000] BIOS-e820: [mem 0x00000000d1a45000-0x00000000d1ecffff] reserved
    [    0.000000] BIOS-e820: [mem 0x00000000d1ed0000-0x00000000d7eeafff] usable
    [    0.000000] BIOS-e820: [mem 0x00000000d7eeb000-0x00000000d7ffffff] reserved
    [    0.000000] BIOS-e820: [mem 0x00000000d8000000-0x00000000d875ffff] usable
    [    0.000000] BIOS-e820: [mem 0x00000000d8760000-0x00000000d87fffff] reserved
    [    0.000000] BIOS-e820: [mem 0x00000000d8800000-0x00000000d8fadfff] usable
    [    0.000000] BIOS-e820: [mem 0x00000000d8fae000-0x00000000d8ffffff] ACPI data
    [    0.000000] BIOS-e820: [mem 0x00000000d9000000-0x00000000da71bfff] usable
    [    0.000000] BIOS-e820: [mem 0x00000000da71c000-0x00000000da7fffff] ACPI NVS
    [    0.000000] BIOS-e820: [mem 0x00000000da800000-0x00000000dbb8bfff] usable
    [    0.000000] BIOS-e820: [mem 0x00000000dbb8c000-0x00000000dbffffff] reserved
    [    0.000000] BIOS-e820: [mem 0x00000000dd000000-0x00000000df1fffff] reserved
    [    0.000000] BIOS-e820: [mem 0x00000000f8000000-0x00000000fbffffff] reserved
    [    0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
    [    0.000000] BIOS-e820: [mem 0x00000000fed00000-0x00000000fed03fff] reserved
    [    0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
    [    0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
    [    0.000000] BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
    [    0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000041edfffff] usable
    
    Fix this problem by changing pfn limit from max_low_pfn to max_pfn.
    This fix does not impact 64bit system because on 64bit max_low_pfn
    is the same as max_pfn.
    
    Signed-off-by: Zhimin Gu <kookoo.gu@intel.com>
    Acked-by: Pavel Machek <pavel@ucw.cz>
    Signed-off-by: Chen Yu <yu.c.chen@intel.com>
    Acked-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: All applicable <stable@vger.kernel.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1595a964d7afb79530770a2dd6fc83b1676faef0
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Thu Oct 11 12:38:26 2018 +0200

    x86/tsc: Force inlining of cyc2ns bits
    
    commit 4907c68abd3f60f650f98d5a69d4ec77c0bde44f upstream.
    
    Looking at the asm for native_sched_clock() I noticed we don't inline
    enough. Mostly caused by sharing code with cyc2ns_read_begin(), which
    we didn't used to do. So mark all that __force_inline to make it DTRT.
    
    Fixes: 59eaef78bfea ("x86/tsc: Remodel cyc2ns to use seqcount_latch()")
    Reported-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: hpa@zytor.com
    Cc: eric.dumazet@gmail.com
    Cc: bp@alien8.de
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20181011104019.695196158@infradead.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1220de22227bbb2773f31c29c33c1271f2f42890
Author: Phil Auld <pauld@redhat.com>
Date:   Mon Oct 8 10:36:40 2018 -0400

    sched/fair: Fix throttle_list starvation with low CFS quota
    
    commit baa9be4ffb55876923dc9716abc0a448e510ba30 upstream.
    
    With a very low cpu.cfs_quota_us setting, such as the minimum of 1000,
    distribute_cfs_runtime may not empty the throttled_list before it runs
    out of runtime to distribute. In that case, due to the change from
    c06f04c7048 to put throttled entries at the head of the list, later entries
    on the list will starve.  Essentially, the same X processes will get pulled
    off the list, given CPU time and then, when expired, get put back on the
    head of the list where distribute_cfs_runtime will give runtime to the same
    set of processes leaving the rest.
    
    Fix the issue by setting a bit in struct cfs_bandwidth when
    distribute_cfs_runtime is running, so that the code in throttle_cfs_rq can
    decide to put the throttled entry on the tail or the head of the list.  The
    bit is set/cleared by the callers of distribute_cfs_runtime while they hold
    cfs_bandwidth->lock.
    
    This is easy to reproduce with a handful of CPU consumers. I use 'crash' on
    the live system. In some cases you can simply look at the throttled list and
    see the later entries are not changing:
    
      crash> list cfs_rq.throttled_list -H 0xffff90b54f6ade40 -s cfs_rq.runtime_remaining | paste - - | awk '{print $1"  "$4}' | pr -t -n3
        1     ffff90b56cb2d200  -976050
        2     ffff90b56cb2cc00  -484925
        3     ffff90b56cb2bc00  -658814
        4     ffff90b56cb2ba00  -275365
        5     ffff90b166a45600  -135138
        6     ffff90b56cb2da00  -282505
        7     ffff90b56cb2e000  -148065
        8     ffff90b56cb2fa00  -872591
        9     ffff90b56cb2c000  -84687
       10     ffff90b56cb2f000  -87237
       11     ffff90b166a40a00  -164582
    
      crash> list cfs_rq.throttled_list -H 0xffff90b54f6ade40 -s cfs_rq.runtime_remaining | paste - - | awk '{print $1"  "$4}' | pr -t -n3
        1     ffff90b56cb2d200  -994147
        2     ffff90b56cb2cc00  -306051
        3     ffff90b56cb2bc00  -961321
        4     ffff90b56cb2ba00  -24490
        5     ffff90b166a45600  -135138
        6     ffff90b56cb2da00  -282505
        7     ffff90b56cb2e000  -148065
        8     ffff90b56cb2fa00  -872591
        9     ffff90b56cb2c000  -84687
       10     ffff90b56cb2f000  -87237
       11     ffff90b166a40a00  -164582
    
    Sometimes it is easier to see by finding a process getting starved and looking
    at the sched_info:
    
      crash> task ffff8eb765994500 sched_info
      PID: 7800   TASK: ffff8eb765994500  CPU: 16  COMMAND: "cputest"
        sched_info = {
          pcount = 8,
          run_delay = 697094208,
          last_arrival = 240260125039,
          last_queued = 240260327513
        },
      crash> task ffff8eb765994500 sched_info
      PID: 7800   TASK: ffff8eb765994500  CPU: 16  COMMAND: "cputest"
        sched_info = {
          pcount = 8,
          run_delay = 697094208,
          last_arrival = 240260125039,
          last_queued = 240260327513
        },
    
    Signed-off-by: Phil Auld <pauld@redhat.com>
    Reviewed-by: Ben Segall <bsegall@google.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Fixes: c06f04c70489 ("sched: Fix potential near-infinite distribute_cfs_runtime() loop")
    Link: http://lkml.kernel.org/r/20181008143639.GA4019@pauld.bos.csb
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e5c0a5893c0443d943b0a411802e3e463664c737
Author: Mikhail Nikiforov <jackxviichaos@gmail.com>
Date:   Mon Oct 15 11:17:56 2018 -0700

    Input: elan_i2c - add ACPI ID for Lenovo IdeaPad 330-15IGM
    
    commit 13c1c5e4d7f887cba36c5e3df3faa22071c1469f upstream.
    
    Add ELAN061C to the ACPI table to support Elan touchpad found in Lenovo
    IdeaPad 330-15IGM.
    
    Signed-off-by: Mikhail Nikiforov <jackxviichaos@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dad71807595250788821346805ee8976efcc7f29
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Mon Oct 15 16:55:04 2018 -0400

    USB: fix the usbfs flag sanitization for control transfers
    
    commit 665c365a77fbfeabe52694aedf3446d5f2f1ce42 upstream.
    
    Commit 7a68d9fb8510 ("USB: usbdevfs: sanitize flags more") checks the
    transfer flags for URBs submitted from userspace via usbfs.  However,
    the check for whether the USBDEVFS_URB_SHORT_NOT_OK flag should be
    allowed for a control transfer was added in the wrong place, before
    the code has properly determined the direction of the control
    transfer.  (Control transfers are special because for them, the
    direction is set by the bRequestType byte of the Setup packet rather
    than direction bit of the endpoint address.)
    
    This patch moves code which sets up the allow_short flag for control
    transfers down after is_in has been set to the correct value.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-and-tested-by: syzbot+24a30223a4b609bb802e@syzkaller.appspotmail.com
    Fixes: 7a68d9fb8510 ("USB: usbdevfs: sanitize flags more")
    CC: Oliver Neukum <oneukum@suse.com>
    CC: <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 509015954a0c67ba7c34dadaf0d3fffde8c482c7
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Tue Oct 16 12:16:45 2018 +0200

    usb: gadget: storage: Fix Spectre v1 vulnerability
    
    commit 9ae24af3669111d418242caec8dd4ebd9ba26860 upstream.
    
    num can be indirectly controlled by user-space, hence leading to
    a potential exploitation of the Spectre variant 1 vulnerability.
    
    This issue was detected with the help of Smatch:
    
    drivers/usb/gadget/function/f_mass_storage.c:3177 fsg_lun_make() warn:
    potential spectre issue 'fsg_opts->common->luns' [r] (local cap)
    
    Fix this by sanitizing num before using it to index
    fsg_opts->common->luns
    
    Notice that given that speculation windows are large, the policy is
    to kill the speculation on the first load and not worry if it can be
    completed with a dependent load/store [1].
    
    [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
    Acked-by: Felipe Balbi <felipe.balbi@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 89cd15c962405428bcd11c5f34127698f29bbd60
Author: Shuah Khan (Samsung OSG) <shuah@kernel.org>
Date:   Fri Oct 5 16:17:44 2018 -0600

    usb: usbip: Fix BUG: KASAN: slab-out-of-bounds in vhci_hub_control()
    
    commit 81f7567c51ad97668d1c3a48e8ecc482e64d4161 upstream.
    
    vhci_hub_control() accesses port_status array with out of bounds port
    value. Fix it to reference port_status[] only with a valid rhport value
    when invalid_rhport flag is true.
    
    The invalid_rhport flag is set early on after detecting in port value
    is within the bounds or not.
    
    The following is used reproduce the problem and verify the fix:
    C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14ed8ab6400000
    
    Reported-by: syzbot+bccc1fe10b70fadc78d0@syzkaller.appspotmail.com
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Shuah Khan (Samsung OSG) <shuah@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6f053e36bda96461245d0d01f374dac4f7cab54c
Author: Oliver Neukum <oneukum@suse.com>
Date:   Thu Oct 4 15:49:06 2018 +0200

    cdc-acm: fix race between reset and control messaging
    
    commit 9397940ed812b942c520e0c25ed4b2c64d57e8b9 upstream.
    
    If a device splits up a control message and a reset() happens
    between the parts, the message is lost and already recieved parts
    must be dropped.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Fixes: 1aba579f3cf51 ("cdc-acm: handle read pipe errors")
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 32772ef3f5ed990404c7664782ad77c551d19693
Author: Tobias Herzog <t-herzog@gmx.de>
Date:   Sat Sep 22 22:11:11 2018 +0200

    cdc-acm: correct counting of UART states in serial state notification
    
    commit f976d0e5747ca65ccd0fb2a4118b193d70aa1836 upstream.
    
    The usb standard ("Universal Serial Bus Class Definitions for Communication
    Devices") distiguishes between "consistent signals" (DSR, DCD), and
    "irregular signals" (break, ring, parity error, framing error, overrun).
    The bits of "irregular signals" are set, if this error/event occurred on
    the device side and are immeadeatly unset, if the serial state notification
    was sent.
    Like other drivers of real serial ports do, just the occurence of those
    events should be counted in serial_icounter_struct (but no 1->0
    transitions).
    
    Signed-off-by: Tobias Herzog <t-herzog@gmx.de>
    Acked-by: Oliver Neukum <oneukum@suse.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8686f337ca17db405ca770c490e725088be58414
Author: Tobias Herzog <t-herzog@gmx.de>
Date:   Sat Sep 22 22:11:10 2018 +0200

    cdc-acm: do not reset notification buffer index upon urb unlinking
    
    commit dae3ddba36f8c337fb59cef07d564da6fc9b7551 upstream.
    
    Resetting the write index of the notification buffer on urb unlink (e.g.
    closing a cdc-acm device from userspace) may lead to wrong interpretation
    of further received notifications, in case the index is not 0 when urb
    unlink happens (i.e. when parts of a notification already have been
    transferred). On the device side there is no "reset" of the notification
    transimission and thus we would get out of sync with the device.
    
    Signed-off-by: Tobias Herzog <t-herzog@gmx.de>
    Acked-by: Oliver Neukum <oneukum@suse.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f0e3b74a4dc0ce27abccdfdcd41eae73cee4b9ac
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Tue Oct 16 16:32:40 2018 +0200

    IB/ucm: Fix Spectre v1 vulnerability
    
    commit 0295e39595e1146522f2722715dba7f7fba42217 upstream.
    
    hdr.cmd can be indirectly controlled by user-space, hence leading to
    a potential exploitation of the Spectre variant 1 vulnerability.
    
    This issue was detected with the help of Smatch:
    
    drivers/infiniband/core/ucm.c:1127 ib_ucm_write() warn: potential
    spectre issue 'ucm_cmd_table' [r] (local cap)
    
    Fix this by sanitizing hdr.cmd before using it to index
    ucm_cmd_table.
    
    Notice that given that speculation windows are large, the policy is
    to kill the speculation on the first load and not worry if it can be
    completed with a dependent load/store [1].
    
    [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 66448066c2b1ec587e6168a9206ffedd11d94444
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Tue Oct 16 16:59:01 2018 +0200

    RDMA/ucma: Fix Spectre v1 vulnerability
    
    commit a3671a4f973ee9d9621d60166cc3b037c397d604 upstream.
    
    hdr.cmd can be indirectly controlled by user-space, hence leading to
    a potential exploitation of the Spectre variant 1 vulnerability.
    
    This issue was detected with the help of Smatch:
    
    drivers/infiniband/core/ucma.c:1686 ucma_write() warn: potential
    spectre issue 'ucma_cmd_table' [r] (local cap)
    
    Fix this by sanitizing hdr.cmd before using it to index
    ucm_cmd_table.
    
    Notice that given that speculation windows are large, the policy is
    to kill the speculation on the first load and not worry if it can be
    completed with a dependent load/store [1].
    
    [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c219c2cd34cc1bbf7dc9ffe04c5d7d411349e7c0
Author: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Date:   Wed Oct 3 19:45:38 2018 +0300

    drm: fb-helper: Reject all pixel format changing requests
    
    commit db05c481977599236f12a85e55de9f5ab37b0a2c upstream.
    
    drm fbdev emulation doesn't support changing the pixel format at all,
    so reject all pixel format changing requests.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
    Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/20181003164538.5534-1-Eugeniy.Paltsev@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 20ff18553ed84b2bc57567e1ac51bf432719c289
Author: Clint Taylor <clinton.a.taylor@intel.com>
Date:   Fri Oct 5 14:52:15 2018 -0700

    drm/edid: VSDB yCBCr420 Deep Color mode bit definitions
    
    commit 9068e02f58740778d8270840657f1e250a2cc60f upstream.
    
    HDMI Forum VSDB YCBCR420 deep color capability bits are 2:0. Correct
    definitions in the header for the mask to work correctly.
    
    Fixes: e6a9a2c3dc43 ("drm/edid: parse ycbcr 420 deep color information")
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107893
    Cc: <stable@vger.kernel.org> # v4.14+
    Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
    Reviewed-by: Jani Nikula <jani.nikula@intel.com>
    Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/1538776335-12569-1-git-send-email-clinton.a.taylor@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fd3127215babb993c7470dc556e547f5572ca371
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Tue Oct 2 23:29:11 2018 +0800

    drm/edid: Add 6 bpc quirk for BOE panel in HP Pavilion 15-n233sl
    
    commit 0711a43b6d84ff9189adfbf83c8bbf56eef794bf upstream.
    
    There's another panel that reports "DFP 1.x compliant TMDS" but it
    supports 6bpc instead of 8 bpc.
    
    Apply 6 bpc quirk for the panel to fix it.
    
    BugLink: https://bugs.launchpad.net/bugs/1794387
    Cc: <stable@vger.kernel.org> # v4.8+
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/20181002152911.4370-1-kai.heng.feng@canonical.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a4b046b0ce973f641d1b6ba4c6947ed94d77a80
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Tue Oct 16 15:06:41 2018 +0200

    ptp: fix Spectre v1 vulnerability
    
    commit efa61c8cf2950ab5c0e66cff3cabe2a2b24e81ba upstream.
    
    pin_index can be indirectly controlled by user-space, hence leading
    to a potential exploitation of the Spectre variant 1 vulnerability.
    
    This issue was detected with the help of Smatch:
    
    drivers/ptp/ptp_chardev.c:253 ptp_ioctl() warn: potential spectre issue
    'ops->pin_config' [r] (local cap)
    
    Fix this by sanitizing pin_index before using it to index
    ops->pin_config, and before passing it as an argument to
    function ptp_set_pinfunc(), in which it is used to index
    info->pin_config.
    
    Notice that given that speculation windows are large, the policy is
    to kill the speculation on the first load and not worry if it can be
    completed with a dependent load/store [1].
    
    [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
    Acked-by: Richard Cochran <richardcochran@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ddb595dfe47278fd8ff3fd171b3729ec45d51b74
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Wed Oct 17 15:23:26 2018 +0100

    cachefiles: fix the race between cachefiles_bury_object() and rmdir(2)
    
    commit 169b803397499be85bdd1e3d07d6f5e3d4bd669e upstream.
    
    the victim might've been rmdir'ed just before the lock_rename();
    unlike the normal callers, we do not look the source up after the
    parents are locked - we know it beforehand and just recheck that it's
    still the child of what used to be its parent.  Unfortunately,
    the check is too weak - we don't spot a dead directory since its
    ->d_parent is unchanged, dentry is positive, etc.  So we sail all
    the way to ->rename(), with hosting filesystems _not_ expecting
    to be asked renaming an rmdir'ed subdirectory.
    
    The fix is easy, fortunately - the lock on parent is sufficient for
    making IS_DEADDIR() on child safe.
    
    Cc: stable@vger.kernel.org
    Fixes: 9ae326a69004 (CacheFiles: A cache that backs onto a mounted filesystem)
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 33e52eb2d00582fad17177918b83a8df19958989
Author: Brian Foster <bfoster@redhat.com>
Date:   Sat Nov 3 19:15:24 2018 +0200

    xfs: truncate transaction does not modify the inobt
    
    [ Upstream commit a606ebdb859e78beb757dfefa08001df366e2ef5 ]
    
    The truncate transaction does not ever modify the inode btree, but
    includes an associated log reservation. Update
    xfs_calc_itruncate_reservation() to remove the reservation
    associated with inobt updates.
    
    [Amir:  This commit was merged for kernel v4.16 and a twin commit was
            merged for xfsprogs v4.16. As a result, a small xfs filesystem
            formatted with features -m rmapbt=1,reflink=1 using mkfs.xfs
            version >= v4.16 cannot be mounted with kernel < v4.16.
    
            For example, xfstests generic/17{1,2,3} format a small fs and
            when trying to mount it, they fail with an assert on this very
            demonic line:
    
     XFS (vdc): Log size 3075 blocks too small, minimum size is 3717 blocks
     XFS (vdc): AAIEEE! Log failed size checks. Abort!
     XFS: Assertion failed: 0, file: src/linux/fs/xfs/xfs_log.c, line: 666
    
            The simple solution for stable kernels is to apply this patch,
            because mkfs.xfs v4.16 is already in the wild, so we have to
            assume that xfs filesystems with a "too small" log exist.
            Regardless, xfsprogs maintainers should also consider reverting
            the twin patch to stop creating those filesystems for the sake
            of users with unpatched kernels.]
    
    Signed-off-by: Brian Foster <bfoster@redhat.com>
    Reviewed-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
    Cc: <stable@vger.kernel.org> # v4.9+
    Signed-off-by: Amir Goldstein <amir73il@gmail.com>
    Reviewed-by: Darrick J . Wong <darrick.wong@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 43607eb9f70823072e1bfc27f84ed81551ac2adb
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Wed Aug 29 17:02:16 2018 +0200

    gpio: mxs: Get rid of external API call
    
    [ Upstream commit 833eacc7b5913da9896bacd30db7d490aa777868 ]
    
    The MXS driver was calling back into the GPIO API from
    its irqchip. This is not very elegant, as we are a driver,
    let's just shortcut back into the gpio_chip .get() function
    instead.
    
    This is a tricky case since the .get() callback is not in
    this file, instead assigned by bgpio_init(). Calling the
    function direcly in the gpio_chip is however the lesser
    evil.
    
    Cc: Sascha Hauer <s.hauer@pengutronix.de>
    Cc: Janusz Uzycki <j.uzycki@elproma.com.pl>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6eb5633da44ef52e37c27e25400d427b9774ae6e
Author: Amir Goldstein <amir73il@gmail.com>
Date:   Sat Sep 1 09:40:01 2018 +0300

    fsnotify: fix ignore mask logic in fsnotify()
    
    [ Upstream commit 9bdda4e9cf2dcecb60a0683b10ffb8cd7e5f2f45 ]
    
    Commit 92183a42898d ("fsnotify: fix ignore mask logic in
    send_to_group()") acknoledges the use case of ignoring an event on
    an inode mark, because of an ignore mask on a mount mark of the same
    group (i.e. I want to get all events on this file, except for the events
    that came from that mount).
    
    This change depends on correctly merging the inode marks and mount marks
    group lists, so that the mount mark ignore mask would be tested in
    send_to_group(). Alas, the merging of the lists did not take into
    account the case where event in question is not in the mask of any of
    the mount marks.
    
    To fix this, completely remove the tests for inode and mount event masks
    from the lists merging code.
    
    Fixes: 92183a42898d ("fsnotify: fix ignore mask logic in send_to_group")
    Signed-off-by: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    [amir: backport to v4.14.y]
    Signed-off-by: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0502f1366921284a8f418db753d9fd7af4cd5ba8
Author: Sasha Levin <sashal@kernel.org>
Date:   Tue Nov 6 01:23:39 2018 -0500

    Revert "ARM: tegra: Fix ULPI regression on Tegra20"
    
    This reverts commit b39ac54215190bc178ae7de799e74d327a3c1a33.
    
    The issue was fixed by upstream commit 5d797111afe1 ("clk:
    tegra: Add quirk for getting CDEV1/2 clocks on Tegra20").
    
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eb9b195c53db75c694bf78576925fcb3eed9d0e1
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Thu Nov 1 22:30:38 2018 +0100

    bpf: fix partial copy of map_ptr when dst is scalar
    
    commit 0962590e553331db2cc0aef2dc35c57f6300dbbe upstream.
    
    ALU operations on pointers such as scalar_reg += map_value_ptr are
    handled in adjust_ptr_min_max_vals(). Problem is however that map_ptr
    and range in the register state share a union, so transferring state
    through dst_reg->range = ptr_reg->range is just buggy as any new
    map_ptr in the dst_reg is then truncated (or null) for subsequent
    checks. Fix this by adding a raw member and use it for copying state
    over to dst_reg.
    
    Fixes: f1174f77b50c ("bpf/verifier: rework value tracking")
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Cc: Edward Cree <ecree@solarflare.com>
    Acked-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Acked-by: Edward Cree <ecree@solarflare.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cc2526f1f5544a440c88f48c4681707ca76e3df1
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Nov 1 20:52:47 2018 +0100

    USB: serial: option: add two-endpoints device-id flag
    
    commit 35aecc02b5b621782111f64cbb032c7f6a90bb32 upstream
    
    Allow matching on interfaces having two endpoints by adding a new
    device-id flag.
    
    This allows for the handling of devices whose interface numbers can
    change (e.g. Quectel EP06) to be contained in the device-id table.
    
    The upstream commit removes a variable that is still in use in the 4.14
    version of the option-driver, so the removal is undone.
    
    Tested-by: Kristian Evensen <kristian.evensen@gmail.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Kristian Evensen <kristian.evensen@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 86534d3d824351868fb0992e13777933edb91e6f
Author: Kristian Evensen <kristian.evensen@gmail.com>
Date:   Thu Nov 1 20:52:46 2018 +0100

    USB: serial: option: improve Quectel EP06 detection
    
    commit 36cae568404a298a19a6e8a3f18641075d4cab04 upstream
    
    The Quectel EP06 (and EM06/EG06) LTE modem supports updating the USB
    configuration, without the VID/PID or configuration number changing.
    When the configuration is updated and interfaces are added/removed, the
    interface numbers are updated. This causes our current code for matching
    EP06 not to work as intended, as the assumption about reserved
    interfaces no longer holds. If for example the diagnostic (first)
    interface is removed, option will (try to) bind to the QMI interface.
    
    This patch improves EP06 detection by replacing the current match with
    two matches, and those matches check class, subclass and protocol as
    well as VID and PID. The diag interface exports class, subclass and
    protocol as 0xff. For the other serial interfaces, class is 0xff and
    subclass and protocol are both 0x0.
    
    The modem can export the following devices and always in this order:
    diag, nmea, at, ppp. qmi and adb. This means that diag can only ever be
    interface 0, and interface numbers 1-5 should be marked as reserved. The
    three other serial devices can have interface numbers 0-3, but I have
    not marked any interfaces as reserved. The reason is that the serial
    devices are the only interfaces exported by the device where subclass
    and protocol is 0x0.
    
    QMI exports the same class, subclass and protocol values as the diag
    interface. However, the two interfaces have different number of
    endpoints, QMI has three and diag two. I have added a check for number
    of interfaces if VID/PID matches the EP06, and we ignore the device if
    number of interfaces equals three (and subclass is set).
    
    The upstream commit does not apply cleanly to the 4.14-tree because of
    differences in option_probe(). In order to make the commit apply, a
    slight reshuffeling of the code was needed.
    
    Signed-off-by: Kristian Evensen <kristian.evensen@gmail.com>
    Acked-by: Dan Williams <dcbw@redhat.com>
    [ johan: drop uneeded RSVD(5) for ADB ]
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Kristian Evensen <kristian.evensen@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8a6cee344cc0236d6171bc24506cb593d84b8214
Author: Amir Goldstein <amir73il@gmail.com>
Date:   Mon Oct 22 20:56:46 2018 +0300

    vfs: swap names of {do,vfs}_clone_file_range()
    
    commit a725356b6659469d182d662f22d770d83d3bc7b5 upstream.
    
    Commit 031a072a0b8a ("vfs: call vfs_clone_file_range() under freeze
    protection") created a wrapper do_clone_file_range() around
    vfs_clone_file_range() moving the freeze protection to former, so
    overlayfs could call the latter.
    
    The more common vfs practice is to call do_xxx helpers from vfs_xxx
    helpers, where freeze protecction is taken in the vfs_xxx helper, so
    this anomality could be a source of confusion.
    
    It seems that commit 8ede205541ff ("ovl: add reflink/copyfile/dedup
    support") may have fallen a victim to this confusion -
    ovl_clone_file_range() calls the vfs_clone_file_range() helper in the
    hope of getting freeze protection on upper fs, but in fact results in
    overlayfs allowing to bypass upper fs freeze protection.
    
    Swap the names of the two helpers to conform to common vfs practice
    and call the correct helpers from overlayfs and nfsd.
    
    Signed-off-by: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Fixes: 031a072a0b8a ("vfs: call vfs_clone_file_range() under freeze...")
    Signed-off-by: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f63387b9ae1ddf1e121b220ebe917aeed7941054
Author: Alan Chiang <alanx.chiang@intel.com>
Date:   Wed Jul 25 11:20:22 2018 +0800

    eeprom: at24: Add support for address-width property
    
    [ Upstream commit a2b3bf4846e5eed62ea6abb096af2c950961033c ]
    
    Provide a flexible way to determine the addressing bits of eeprom.
    Pass the addressing bits to driver through address-width property.
    
    Signed-off-by: Alan Chiang <alanx.chiang@intel.com>
    Signed-off-by: Andy Yeh <andy.yeh@intel.com>
    Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>