commit 5726a8d0f1958af80ad8e514bc2c18d213e739b7
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Mar 19 13:13:25 2019 +0100

    Linux 4.14.107

commit b384efc1fbb944255c096b9372162de4b4c2ceb7
Author: Zha Bin <zhabin@linux.alibaba.com>
Date:   Tue Jan 8 16:07:03 2019 +0800

    vhost/vsock: fix vhost vsock cid hashing inconsistent
    
    commit 7fbe078c37aba3088359c9256c1a1d0c3e39ee81 upstream.
    
    The vsock core only supports 32bit CID, but the Virtio-vsock spec define
    CID (dst_cid and src_cid) as u64 and the upper 32bits is reserved as
    zero. This inconsistency causes one bug in vhost vsock driver. The
    scenarios is:
    
      0. A hash table (vhost_vsock_hash) is used to map an CID to a vsock
      object. And hash_min() is used to compute the hash key. hash_min() is
      defined as:
      (sizeof(val) <= 4 ? hash_32(val, bits) : hash_long(val, bits)).
      That means the hash algorithm has dependency on the size of macro
      argument 'val'.
      0. In function vhost_vsock_set_cid(), a 64bit CID is passed to
      hash_min() to compute the hash key when inserting a vsock object into
      the hash table.
      0. In function vhost_vsock_get(), a 32bit CID is passed to hash_min()
      to compute the hash key when looking up a vsock for an CID.
    
    Because the different size of the CID, hash_min() returns different hash
    key, thus fails to look up the vsock object for an CID.
    
    To fix this bug, we keep CID as u64 in the IOCTLs and virtio message
    headers, but explicitly convert u64 to u32 when deal with the hash table
    and vsock core.
    
    Fixes: 834e772c8db0 ("vhost/vsock: fix use-after-free in network stack callers")
    Link: https://github.com/stefanha/virtio/blob/vsock/trunk/content.tex
    Signed-off-by: Zha Bin <zhabin@linux.alibaba.com>
    Reviewed-by: Liu Jiang <gerry@linux.alibaba.com>
    Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Shengjing Zhu <i@zhsj.me>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c9794e6820ad92bc0fa47ac6a99f63f6bb477225
Author: Xiao Ni <xni@redhat.com>
Date:   Fri Mar 8 23:52:05 2019 +0800

    It's wrong to add len to sector_nr in raid10 reshape twice
    
    commit b761dcf1217760a42f7897c31dcb649f59b2333e upstream.
    
    In reshape_request it already adds len to sector_nr already. It's wrong to add len to
    sector_nr again after adding pages to bio. If there is bad block it can't copy one chunk
    at a time, it needs to goto read_more. Now the sector_nr is wrong. It can cause data
    corruption.
    
    Cc: stable@vger.kernel.org # v3.16+
    Signed-off-by: Xiao Ni <xni@redhat.com>
    Signed-off-by: Song Liu <songliubraving@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 94b2a2c534f5a01fb8e93857cf376528c599502c
Author: kbuild test robot <lkp@intel.com>
Date:   Thu Mar 14 02:42:43 2019 +0800

    perf/x86/intel: Make dev_attr_allow_tsx_force_abort static
    
    commit c634dc6bdedeb0b2c750fc611612618a85639ab2 upstream.
    
    Fixes: 400816f60c54 ("perf/x86/intel: Implement support for TSX Force Abort")
    Signed-off-by: kbuild test robot <lkp@intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
    Cc: kbuild-all@01.org
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190313184243.GA10820@lkp-sb-ep06
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a003d3333f2cb41ced9183506397ccb6a0571eb
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Thu Mar 14 14:01:14 2019 +0100

    perf/x86/intel: Fix memory corruption
    
    commit ede271b059463731cbd6dffe55ffd70d7dbe8392 upstream.
    
    Through:
    
      validate_event()
        x86_pmu.get_event_constraints(.idx=-1)
          tfa_get_event_constraints()
            dyn_constraint()
    
    cpuc->constraint_list[-1] is used, which is an obvious out-of-bound access.
    
    In this case, simply skip the TFA constraint code, there is no event
    constraint with just PMC3, therefore the code will never result in the
    empty set.
    
    Fixes: 400816f60c54 ("perf/x86/intel: Implement support for TSX Force Abort")
    Reported-by: Tony Jones <tonyj@suse.com>
    Reported-by: "DSouza, Nelson" <nelson.dsouza@intel.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Tony Jones <tonyj@suse.com>
    Tested-by: "DSouza, Nelson" <nelson.dsouza@intel.com>
    Cc: eranian@google.com
    Cc: jolsa@redhat.com
    Cc: stable@kernel.org
    Link: https://lkml.kernel.org/r/20190314130705.441549378@infradead.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 34cdfe7845089d2762f7439825e582887994ecf5
Author: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Date:   Tue Feb 26 13:38:37 2019 +0900

    ALSA: firewire-motu: fix construction of PCM frame for capture direction
    
    commit f97a0944a72b26a2bece72516294e112a890f98a upstream.
    
    In data blocks of common isochronous packet for MOTU devices, PCM
    frames are multiplexed in a shape of '24 bit * 4 Audio Pack', described
    in IEC 61883-6. The frames are not aligned to quadlet.
    
    For capture PCM substream, ALSA firewire-motu driver constructs PCM
    frames by reading data blocks byte-by-byte. However this operation
    includes bug for lower byte of the PCM sample. This brings invalid
    content of the PCM samples.
    
    This commit fixes the bug.
    
    Reported-by: Peter Sjöberg <autopeter@gmail.com>
    Cc: <stable@vger.kernel.org> # v4.12+
    Fixes: 4641c9394010 ("ALSA: firewire-motu: add MOTU specific protocol layer")
    Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 18d48bd413830eb2df22d06d0573f499185d935c
Author: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Date:   Tue Feb 26 13:38:16 2019 +0900

    ALSA: bebob: use more identical mod_alias for Saffire Pro 10 I/O against Liquid Saffire 56
    
    commit 7dc661bd8d3261053b69e4e2d0050cd1ee540fc1 upstream.
    
    ALSA bebob driver has an entry for Focusrite Saffire Pro 10 I/O. The
    entry matches vendor_id in root directory and model_id in unit
    directory of configuration ROM for IEEE 1394 bus.
    
    On the other hand, configuration ROM of Focusrite Liquid Saffire 56
    has the same vendor_id and model_id. This device is an application of
    TCAT Dice (TCD2220 a.k.a Dice Jr.) however ALSA bebob driver can be
    bound to it randomly instead of ALSA dice driver. At present, drivers
    in ALSA firewire stack can not handle this situation appropriately.
    
    This commit uses more identical mod_alias for Focusrite Saffire Pro 10
    I/O in ALSA bebob driver.
    
    $ python2 crpp < /sys/bus/firewire/devices/fw1/config_rom
                   ROM header and bus information block
                   -----------------------------------------------------------------
    400  042a829d  bus_info_length 4, crc_length 42, crc 33437
    404  31333934  bus_name "1394"
    408  f0649222  irmc 1, cmc 1, isc 1, bmc 1, pmc 0, cyc_clk_acc 100,
                   max_rec 9 (1024), max_rom 2, gen 2, spd 2 (S400)
    40c  00130e01  company_id 00130e     |
    410  000606e0  device_id 01000606e0  | EUI-64 00130e01000606e0
    
                   root directory
                   -----------------------------------------------------------------
    414  0009d31c  directory_length 9, crc 54044
    418  04000014  hardware version
    41c  0c0083c0  node capabilities per IEEE 1394
    420  0300130e  vendor
    424  81000012  --> descriptor leaf at 46c
    428  17000006  model
    42c  81000016  --> descriptor leaf at 484
    430  130120c2  version
    434  d1000002  --> unit directory at 43c
    438  d4000006  --> dependent info directory at 450
    
                   unit directory at 43c
                   -----------------------------------------------------------------
    43c  0004707c  directory_length 4, crc 28796
    440  1200a02d  specifier id: 1394 TA
    444  13010001  version: AV/C
    448  17000006  model
    44c  81000013  --> descriptor leaf at 498
    
                   dependent info directory at 450
                   -----------------------------------------------------------------
    450  000637c7  directory_length 6, crc 14279
    454  120007f5  specifier id
    458  13000001  version
    45c  3affffc7  (immediate value)
    460  3b100000  (immediate value)
    464  3cffffc7  (immediate value)
    468  3d600000  (immediate value)
    
                   descriptor leaf at 46c
                   -----------------------------------------------------------------
    46c  00056f3b  leaf_length 5, crc 28475
    470  00000000  textual descriptor
    474  00000000  minimal ASCII
    478  466f6375  "Focu"
    47c  73726974  "srit"
    480  65000000  "e"
    
                   descriptor leaf at 484
                   -----------------------------------------------------------------
    484  0004a165  leaf_length 4, crc 41317
    488  00000000  textual descriptor
    48c  00000000  minimal ASCII
    490  50726f31  "Pro1"
    494  30494f00  "0IO"
    
                   descriptor leaf at 498
                   -----------------------------------------------------------------
    498  0004a165  leaf_length 4, crc 41317
    49c  00000000  textual descriptor
    4a0  00000000  minimal ASCII
    4a4  50726f31  "Pro1"
    4a8  30494f00  "0IO"
    
    $ python2 crpp < /sys/bus/firewire/devices/fw1/config_rom
                   ROM header and bus information block
                   -----------------------------------------------------------------
    400  040442e4  bus_info_length 4, crc_length 4, crc 17124
    404  31333934  bus_name "1394"
    408  e0ff8112  irmc 1, cmc 1, isc 1, bmc 0, pmc 0, cyc_clk_acc 255,
                   max_rec 8 (512), max_rom 1, gen 1, spd 2 (S400)
    40c  00130e04  company_id 00130e     |
    410  018001e9  device_id 04018001e9  | EUI-64 00130e04018001e9
    
                   root directory
                   -----------------------------------------------------------------
    414  00065612  directory_length 6, crc 22034
    418  0300130e  vendor
    41c  8100000a  --> descriptor leaf at 444
    420  17000006  model
    424  8100000e  --> descriptor leaf at 45c
    428  0c0087c0  node capabilities per IEEE 1394
    42c  d1000001  --> unit directory at 430
    
                   unit directory at 430
                   -----------------------------------------------------------------
    430  000418a0  directory_length 4, crc 6304
    434  1200130e  specifier id
    438  13000001  version
    43c  17000006  model
    440  8100000f  --> descriptor leaf at 47c
    
                   descriptor leaf at 444
                   -----------------------------------------------------------------
    444  00056f3b  leaf_length 5, crc 28475
    448  00000000  textual descriptor
    44c  00000000  minimal ASCII
    450  466f6375  "Focu"
    454  73726974  "srit"
    458  65000000  "e"
    
                   descriptor leaf at 45c
                   -----------------------------------------------------------------
    45c  000762c6  leaf_length 7, crc 25286
    460  00000000  textual descriptor
    464  00000000  minimal ASCII
    468  4c495155  "LIQU"
    46c  49445f53  "ID_S"
    470  41464649  "AFFI"
    474  52455f35  "RE_5"
    478  36000000  "6"
    
                   descriptor leaf at 47c
                   -----------------------------------------------------------------
    47c  000762c6  leaf_length 7, crc 25286
    480  00000000  textual descriptor
    484  00000000  minimal ASCII
    488  4c495155  "LIQU"
    48c  49445f53  "ID_S"
    490  41464649  "AFFI"
    494  52455f35  "RE_5"
    498  36000000  "6"
    
    Cc: <stable@vger.kernel.org> # v3.16+
    Fixes: 25784ec2d034 ("ALSA: bebob: Add support for Focusrite Saffire/SaffirePro series")
    Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 578aa457dad7831a420592890141cd6de6465006
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Fri Mar 15 09:14:10 2019 +0100

    perf/x86: Fixup typo in stub functions
    
    commit f764c58b7faa26f5714e6907f892abc2bc0de4f8 upstream.
    
    Guenter reported a build warning for CONFIG_CPU_SUP_INTEL=n:
    
      > With allmodconfig-CONFIG_CPU_SUP_INTEL, this patch results in:
      >
      > In file included from arch/x86/events/amd/core.c:8:0:
      > arch/x86/events/amd/../perf_event.h:1036:45: warning: ‘struct cpu_hw_event’ declared inside parameter list will not be visible outside of this definition or declaration
      >  static inline int intel_cpuc_prepare(struct cpu_hw_event *cpuc, int cpu)
    
    While harmless (an unsed pointer is an unused pointer, no matter the type)
    it needs fixing.
    
    Reported-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    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: d01b1f96a82e ("perf/x86/intel: Make cpuc allocations consistent")
    Link: http://lkml.kernel.org/r/20190315081410.GR5996@hirez.programming.kicks-ass.net
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ddcc3253f8dd3dae3b131e319fe8217a687a2cd2
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Wed Feb 20 00:15:30 2019 +0100

    ipvlan: disallow userns cap_net_admin to change global mode/flags
    
    [ Upstream commit 7cc9f7003a969d359f608ebb701d42cafe75b84a ]
    
    When running Docker with userns isolation e.g. --userns-remap="default"
    and spawning up some containers with CAP_NET_ADMIN under this realm, I
    noticed that link changes on ipvlan slave device inside that container
    can affect all devices from this ipvlan group which are in other net
    namespaces where the container should have no permission to make changes
    to, such as the init netns, for example.
    
    This effectively allows to undo ipvlan private mode and switch globally to
    bridge mode where slaves can communicate directly without going through
    hostns, or it allows to switch between global operation mode (l2/l3/l3s)
    for everyone bound to the given ipvlan master device. libnetwork plugin
    here is creating an ipvlan master and ipvlan slave in hostns and a slave
    each that is moved into the container's netns upon creation event.
    
    * In hostns:
    
      # ip -d a
      [...]
      8: cilium_host@bond0: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
         link/ether 0c:c4:7a:e1:3d:cc brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 65535
         ipvlan  mode l3 bridge numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
         inet 10.41.0.1/32 scope link cilium_host
           valid_lft forever preferred_lft forever
      [...]
    
    * Spawn container & change ipvlan mode setting inside of it:
    
      # docker run -dt --cap-add=NET_ADMIN --network cilium-net --name client -l app=test cilium/netperf
      9fff485d69dcb5ce37c9e33ca20a11ccafc236d690105aadbfb77e4f4170879c
    
      # docker exec -ti client ip -d a
      [...]
      10: cilium0@if4: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
          link/ether 0c:c4:7a:e1:3d:cc brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 65535
          ipvlan  mode l3 bridge numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
          inet 10.41.197.43/32 brd 10.41.197.43 scope global cilium0
             valid_lft forever preferred_lft forever
    
      # docker exec -ti client ip link change link cilium0 name cilium0 type ipvlan mode l2
    
      # docker exec -ti client ip -d a
      [...]
      10: cilium0@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
          link/ether 0c:c4:7a:e1:3d:cc brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 65535
          ipvlan  mode l2 bridge numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
          inet 10.41.197.43/32 brd 10.41.197.43 scope global cilium0
             valid_lft forever preferred_lft forever
    
    * In hostns (mode switched to l2):
    
      # ip -d a
      [...]
      8: cilium_host@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
          link/ether 0c:c4:7a:e1:3d:cc brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 65535
          ipvlan  mode l2 bridge numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
          inet 10.41.0.1/32 scope link cilium_host
             valid_lft forever preferred_lft forever
      [...]
    
    Same l3 -> l2 switch would also happen by creating another slave inside
    the container's network namespace when specifying the existing cilium0
    link to derive the actual (bond0) master:
    
      # docker exec -ti client ip link add link cilium0 name cilium1 type ipvlan mode l2
    
      # docker exec -ti client ip -d a
      [...]
      2: cilium1@if4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
          link/ether 0c:c4:7a:e1:3d:cc brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 65535
          ipvlan  mode l2 bridge numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
      10: cilium0@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
          link/ether 0c:c4:7a:e1:3d:cc brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 65535
          ipvlan  mode l2 bridge numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
          inet 10.41.197.43/32 brd 10.41.197.43 scope global cilium0
             valid_lft forever preferred_lft forever
    
    * In hostns:
    
      # ip -d a
      [...]
      8: cilium_host@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
          link/ether 0c:c4:7a:e1:3d:cc brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 65535
          ipvlan  mode l2 bridge numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
          inet 10.41.0.1/32 scope link cilium_host
             valid_lft forever preferred_lft forever
      [...]
    
    One way to mitigate it is to check CAP_NET_ADMIN permissions of
    the ipvlan master device's ns, and only then allow to change
    mode or flags for all devices bound to it. Above two cases are
    then disallowed after the patch.
    
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Mahesh Bandewar <maheshb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 727a261969faaaa47262329dad10816188c75a6b
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Fri Feb 15 20:09:35 2019 +0000

    missing barriers in some of unix_sock ->addr and ->path accesses
    
    [ Upstream commit ae3b564179bfd06f32d051b9e5d72ce4b2a07c37 ]
    
    Several u->addr and u->path users are not holding any locks in
    common with unix_bind().  unix_state_lock() is useless for those
    purposes.
    
    u->addr is assign-once and *(u->addr) is fully set up by the time
    we set u->addr (all under unix_table_lock).  u->path is also
    set in the same critical area, also before setting u->addr, and
    any unix_sock with ->path filled will have non-NULL ->addr.
    
    So setting ->addr with smp_store_release() is all we need for those
    "lockless" users - just have them fetch ->addr with smp_load_acquire()
    and don't even bother looking at ->path if they see NULL ->addr.
    
    Users of ->addr and ->path fall into several classes now:
        1) ones that do smp_load_acquire(u->addr) and access *(u->addr)
    and u->path only if smp_load_acquire() has returned non-NULL.
        2) places holding unix_table_lock.  These are guaranteed that
    *(u->addr) is seen fully initialized.  If unix_sock is in one of the
    "bound" chains, so's ->path.
        3) unix_sock_destructor() using ->addr is safe.  All places
    that set u->addr are guaranteed to have seen all stores *(u->addr)
    while holding a reference to u and unix_sock_destructor() is called
    when (atomic) refcount hits zero.
        4) unix_release_sock() using ->path is safe.  unix_bind()
    is serialized wrt unix_release() (normally - by struct file
    refcount), and for the instances that had ->path set by unix_bind()
    unix_release_sock() comes from unix_release(), so they are fine.
    Instances that had it set in unix_stream_connect() either end up
    attached to a socket (in unix_accept()), in which case the call
    chain to unix_release_sock() and serialization are the same as in
    the previous case, or they never get accept'ed and unix_release_sock()
    is called when the listener is shut down and its queue gets purged.
    In that case the listener's queue lock provides the barriers needed -
    unix_stream_connect() shoves our unix_sock into listener's queue
    under that lock right after having set ->path and eventual
    unix_release_sock() caller picks them from that queue under the
    same lock right before calling unix_release_sock().
        5) unix_find_other() use of ->path is pointless, but safe -
    it happens with successful lookup by (abstract) name, so ->path.dentry
    is guaranteed to be NULL there.
    
    earlier-variant-reviewed-by: "Paul E. McKenney" <paulmck@linux.ibm.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c338fafab643efe92229caf9a4d301d92ff9fd1
Author: Michal Soltys <soltys@ziu.info>
Date:   Mon Feb 18 17:55:28 2019 +0100

    bonding: fix PACKET_ORIGDEV regression
    
    [ Upstream commit 3c963a3306eada999be5ebf4f293dfa3d3945487 ]
    
    This patch fixes a subtle PACKET_ORIGDEV regression which was a side
    effect of fixes introduced by:
    
    6a9e461f6fe4 bonding: pass link-local packets to bonding master also.
    
    ... to:
    
    b89f04c61efe bonding: deliver link-local packets with skb->dev set to link that packets arrived on
    
    While 6a9e461f6fe4 restored pre-b89f04c61efe presence of link-local
    packets on bonding masters (which is required e.g. by linux bridges
    participating in spanning tree or needed for lab-like setups created
    with group_fwd_mask) it also caused the originating device
    information to be lost due to cloning.
    
    Maciej Żenczykowski proposed another solution that doesn't require
    packet cloning and retains original device information - instead of
    returning RX_HANDLER_PASS for all link-local packets it's now limited
    only to packets from inactive slaves.
    
    At the same time, packets passed to bonding masters retain correct
    information about the originating device and PACKET_ORIGDEV can be used
    to determine it.
    
    This elegantly solves all issues so far:
    
    - link-local packets that were removed from bonding masters
    - LLDP daemons being forced to explicitly bind to slave interfaces
    - PACKET_ORIGDEV having no effect on bond interfaces
    
    Fixes: 6a9e461f6fe4 (bonding: pass link-local packets to bonding master also.)
    Reported-by: Vincent Bernat <vincent@bernat.ch>
    Signed-off-by: Michal Soltys <soltys@ziu.info>
    Signed-off-by: Maciej Żenczykowski <maze@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b3dc5b185072520422e26d8bd1a65203f0713a61
Author: Kalash Nainwal <kalash@arista.com>
Date:   Wed Feb 20 16:23:04 2019 -0800

    net: Set rtm_table to RT_TABLE_COMPAT for ipv6 for tables > 255
    
    [ Upstream commit 97f0082a0592212fc15d4680f5a4d80f79a1687c ]
    
    Set rtm_table to RT_TABLE_COMPAT for ipv6 for tables > 255 to
    keep legacy software happy. This is similar to what was done for
    ipv4 in commit 709772e6e065 ("net: Fix routing tables with
    id > 255 for legacy software").
    
    Signed-off-by: Kalash Nainwal <kalash@arista.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 07c2216c3783daca34ea0d86affb9dfc5346f183
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Thu Feb 21 22:42:01 2019 +0800

    mdio_bus: Fix use-after-free on device_register fails
    
    [ Upstream commit 6ff7b060535e87c2ae14dd8548512abfdda528fb ]
    
    KASAN has found use-after-free in fixed_mdio_bus_init,
    commit 0c692d07842a ("drivers/net/phy/mdio_bus.c: call
    put_device on device_register() failure") call put_device()
    while device_register() fails,give up the last reference
    to the device and allow mdiobus_release to be executed
    ,kfreeing the bus. However in most drives, mdiobus_free
    be called to free the bus while mdiobus_register fails.
    use-after-free occurs when access bus again, this patch
    revert it to let mdiobus_free free the bus.
    
    KASAN report details as below:
    
    BUG: KASAN: use-after-free in mdiobus_free+0x85/0x90 drivers/net/phy/mdio_bus.c:482
    Read of size 4 at addr ffff8881dc824d78 by task syz-executor.0/3524
    
    CPU: 1 PID: 3524 Comm: syz-executor.0 Not tainted 5.0.0-rc7+ #45
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
    Call Trace:
     __dump_stack lib/dump_stack.c:77 [inline]
     dump_stack+0xfa/0x1ce lib/dump_stack.c:113
     print_address_description+0x65/0x270 mm/kasan/report.c:187
     kasan_report+0x149/0x18d mm/kasan/report.c:317
     mdiobus_free+0x85/0x90 drivers/net/phy/mdio_bus.c:482
     fixed_mdio_bus_init+0x283/0x1000 [fixed_phy]
     ? 0xffffffffc0e40000
     ? 0xffffffffc0e40000
     ? 0xffffffffc0e40000
     do_one_initcall+0xfa/0x5ca init/main.c:887
     do_init_module+0x204/0x5f6 kernel/module.c:3460
     load_module+0x66b2/0x8570 kernel/module.c:3808
     __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902
     do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    RIP: 0033:0x462e99
    Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007f6215c19c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
    RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
    RDX: 0000000000000000 RSI: 0000000020000080 RDI: 0000000000000003
    RBP: 00007f6215c19c70 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6215c1a6bc
    R13: 00000000004bcefb R14: 00000000006f7030 R15: 0000000000000004
    
    Allocated by task 3524:
     set_track mm/kasan/common.c:85 [inline]
     __kasan_kmalloc.constprop.3+0xa0/0xd0 mm/kasan/common.c:496
     kmalloc include/linux/slab.h:545 [inline]
     kzalloc include/linux/slab.h:740 [inline]
     mdiobus_alloc_size+0x54/0x1b0 drivers/net/phy/mdio_bus.c:143
     fixed_mdio_bus_init+0x163/0x1000 [fixed_phy]
     do_one_initcall+0xfa/0x5ca init/main.c:887
     do_init_module+0x204/0x5f6 kernel/module.c:3460
     load_module+0x66b2/0x8570 kernel/module.c:3808
     __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902
     do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
    Freed by task 3524:
     set_track mm/kasan/common.c:85 [inline]
     __kasan_slab_free+0x130/0x180 mm/kasan/common.c:458
     slab_free_hook mm/slub.c:1409 [inline]
     slab_free_freelist_hook mm/slub.c:1436 [inline]
     slab_free mm/slub.c:2986 [inline]
     kfree+0xe1/0x270 mm/slub.c:3938
     device_release+0x78/0x200 drivers/base/core.c:919
     kobject_cleanup lib/kobject.c:662 [inline]
     kobject_release lib/kobject.c:691 [inline]
     kref_put include/linux/kref.h:67 [inline]
     kobject_put+0x146/0x240 lib/kobject.c:708
     put_device+0x1c/0x30 drivers/base/core.c:2060
     __mdiobus_register+0x483/0x560 drivers/net/phy/mdio_bus.c:382
     fixed_mdio_bus_init+0x26b/0x1000 [fixed_phy]
     do_one_initcall+0xfa/0x5ca init/main.c:887
     do_init_module+0x204/0x5f6 kernel/module.c:3460
     load_module+0x66b2/0x8570 kernel/module.c:3808
     __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902
     do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
    The buggy address belongs to the object at ffff8881dc824c80
     which belongs to the cache kmalloc-2k of size 2048
    The buggy address is located 248 bytes inside of
     2048-byte region [ffff8881dc824c80, ffff8881dc825480)
    The buggy address belongs to the page:
    page:ffffea0007720800 count:1 mapcount:0 mapping:ffff8881f6c02800 index:0x0 compound_mapcount: 0
    flags: 0x2fffc0000010200(slab|head)
    raw: 02fffc0000010200 0000000000000000 0000000500000001 ffff8881f6c02800
    raw: 0000000000000000 00000000800f000f 00000001ffffffff 0000000000000000
    page dumped because: kasan: bad access detected
    
    Memory state around the buggy address:
     ffff8881dc824c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
     ffff8881dc824c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    >ffff8881dc824d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                                    ^
     ffff8881dc824d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff8881dc824e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    
    Fixes: 0c692d07842a ("drivers/net/phy/mdio_bus.c: call put_device on device_register() failure")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 64a6e35ac51036d309fbcc003e4daae672fb5849
Author: Eric Dumazet <edumazet@google.com>
Date:   Sat Feb 23 13:24:59 2019 -0800

    net/x25: fix a race in x25_bind()
    
    [ Upstream commit 797a22bd5298c2674d927893f46cadf619dad11d ]
    
    syzbot was able to trigger another soft lockup [1]
    
    I first thought it was the O(N^2) issue I mentioned in my
    prior fix (f657d22ee1f "net/x25: do not hold the cpu
    too long in x25_new_lci()"), but I eventually found
    that x25_bind() was not checking SOCK_ZAPPED state under
    socket lock protection.
    
    This means that multiple threads can end up calling
    x25_insert_socket() for the same socket, and corrupt x25_list
    
    [1]
    watchdog: BUG: soft lockup - CPU#0 stuck for 123s! [syz-executor.2:10492]
    Modules linked in:
    irq event stamp: 27515
    hardirqs last  enabled at (27514): [<ffffffff81006673>] trace_hardirqs_on_thunk+0x1a/0x1c
    hardirqs last disabled at (27515): [<ffffffff8100668f>] trace_hardirqs_off_thunk+0x1a/0x1c
    softirqs last  enabled at (32): [<ffffffff8632ee73>] x25_get_neigh+0xa3/0xd0 net/x25/x25_link.c:336
    softirqs last disabled at (34): [<ffffffff86324bc3>] x25_find_socket+0x23/0x140 net/x25/af_x25.c:341
    CPU: 0 PID: 10492 Comm: syz-executor.2 Not tainted 5.0.0-rc7+ #88
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    RIP: 0010:__sanitizer_cov_trace_pc+0x4/0x50 kernel/kcov.c:97
    Code: f4 ff ff ff e8 11 9f ea ff 48 c7 05 12 fb e5 08 00 00 00 00 e9 c8 e9 ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 55 48 89 e5 <48> 8b 75 08 65 48 8b 04 25 40 ee 01 00 65 8b 15 38 0c 92 7e 81 e2
    RSP: 0018:ffff88806e94fc48 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13
    RAX: 1ffff1100d84dac5 RBX: 0000000000000001 RCX: ffffc90006197000
    RDX: 0000000000040000 RSI: ffffffff86324bf3 RDI: ffff88806c26d628
    RBP: ffff88806e94fc48 R08: ffff88806c1c6500 R09: fffffbfff1282561
    R10: fffffbfff1282560 R11: ffffffff89412b03 R12: ffff88806c26d628
    R13: ffff888090455200 R14: dffffc0000000000 R15: 0000000000000000
    FS:  00007f3a107e4700(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f3a107e3db8 CR3: 00000000a5544000 CR4: 00000000001406f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     __x25_find_socket net/x25/af_x25.c:327 [inline]
     x25_find_socket+0x7d/0x140 net/x25/af_x25.c:342
     x25_new_lci net/x25/af_x25.c:355 [inline]
     x25_connect+0x380/0xde0 net/x25/af_x25.c:784
     __sys_connect+0x266/0x330 net/socket.c:1662
     __do_sys_connect net/socket.c:1673 [inline]
     __se_sys_connect net/socket.c:1670 [inline]
     __x64_sys_connect+0x73/0xb0 net/socket.c:1670
     do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    RIP: 0033:0x457e29
    Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
    RSP: 002b:00007f3a107e3c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
    RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457e29
    RDX: 0000000000000012 RSI: 0000000020000200 RDI: 0000000000000005
    RBP: 000000000073c040 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 00007f3a107e46d4
    R13: 00000000004be362 R14: 00000000004ceb98 R15: 00000000ffffffff
    Sending NMI from CPU 0 to CPUs 1:
    NMI backtrace for cpu 1
    CPU: 1 PID: 10493 Comm: syz-executor.3 Not tainted 5.0.0-rc7+ #88
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    RIP: 0010:__read_once_size include/linux/compiler.h:193 [inline]
    RIP: 0010:queued_write_lock_slowpath+0x143/0x290 kernel/locking/qrwlock.c:86
    Code: 4c 8d 2c 01 41 83 c7 03 41 0f b6 45 00 41 38 c7 7c 08 84 c0 0f 85 0c 01 00 00 8b 03 3d 00 01 00 00 74 1a f3 90 41 0f b6 55 00 <41> 38 d7 7c eb 84 d2 74 e7 48 89 df e8 cc aa 4e 00 eb dd be 04 00
    RSP: 0018:ffff888085c47bd8 EFLAGS: 00000206
    RAX: 0000000000000300 RBX: ffffffff89412b00 RCX: 1ffffffff1282560
    RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff89412b00
    RBP: ffff888085c47c70 R08: 1ffffffff1282560 R09: fffffbfff1282561
    R10: fffffbfff1282560 R11: ffffffff89412b03 R12: 00000000000000ff
    R13: fffffbfff1282560 R14: 1ffff11010b88f7d R15: 0000000000000003
    FS:  00007fdd04086700(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007fdd04064db8 CR3: 0000000090be0000 CR4: 00000000001406e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     queued_write_lock include/asm-generic/qrwlock.h:104 [inline]
     do_raw_write_lock+0x1d6/0x290 kernel/locking/spinlock_debug.c:203
     __raw_write_lock_bh include/linux/rwlock_api_smp.h:204 [inline]
     _raw_write_lock_bh+0x3b/0x50 kernel/locking/spinlock.c:312
     x25_insert_socket+0x21/0xe0 net/x25/af_x25.c:267
     x25_bind+0x273/0x340 net/x25/af_x25.c:703
     __sys_bind+0x23f/0x290 net/socket.c:1481
     __do_sys_bind net/socket.c:1492 [inline]
     __se_sys_bind net/socket.c:1490 [inline]
     __x64_sys_bind+0x73/0xb0 net/socket.c:1490
     do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    RIP: 0033:0x457e29
    
    Fixes: 90c27297a9bf ("X.25 remove bkl in bind")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: andrew hendry <andrew.hendry@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 048d7079926598a0ab94582f86b1ef46954ed8ec
Author: Jack Morgenstein <jackm@dev.mellanox.co.il>
Date:   Tue Mar 12 17:05:49 2019 +0200

    net/mlx4_core: Fix qp mtt size calculation
    
    [ Upstream commit 8511a653e9250ef36b95803c375a7be0e2edb628 ]
    
    Calculation of qp mtt size (in function mlx4_RST2INIT_wrapper)
    ultimately depends on function roundup_pow_of_two.
    
    If the amount of memory required by the QP is less than one page,
    roundup_pow_of_two is called with argument zero.  In this case, the
    roundup_pow_of_two result is undefined.
    
    Calling roundup_pow_of_two with a zero argument resulted in the
    following stack trace:
    
    UBSAN: Undefined behaviour in ./include/linux/log2.h:61:13
    shift exponent 64 is too large for 64-bit type 'long unsigned int'
    CPU: 4 PID: 26939 Comm: rping Tainted: G OE 4.19.0-rc1
    Hardware name: Supermicro X9DR3-F/X9DR3-F, BIOS 3.2a 07/09/2015
    Call Trace:
    dump_stack+0x9a/0xeb
    ubsan_epilogue+0x9/0x7c
    __ubsan_handle_shift_out_of_bounds+0x254/0x29d
    ? __ubsan_handle_load_invalid_value+0x180/0x180
    ? debug_show_all_locks+0x310/0x310
    ? sched_clock+0x5/0x10
    ? sched_clock+0x5/0x10
    ? sched_clock_cpu+0x18/0x260
    ? find_held_lock+0x35/0x1e0
    ? mlx4_RST2INIT_QP_wrapper+0xfb1/0x1440 [mlx4_core]
    mlx4_RST2INIT_QP_wrapper+0xfb1/0x1440 [mlx4_core]
    
    Fix this by explicitly testing for zero, and returning one if the
    argument is zero (assuming that the next higher power of 2 in this case
    should be one).
    
    Fixes: c82e9aa0a8bc ("mlx4_core: resource tracking for HCA resources used by guests")
    Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
    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 3d31f62c115e55178d7903a202d1f967c0b7531f
Author: Jack Morgenstein <jackm@dev.mellanox.co.il>
Date:   Tue Mar 12 17:05:48 2019 +0200

    net/mlx4_core: Fix locking in SRIOV mode when switching between events and polling
    
    [ Upstream commit c07d27927f2f2e96fcd27bb9fb330c9ea65612d0 ]
    
    In procedures mlx4_cmd_use_events() and mlx4_cmd_use_polling(), we need to
    guarantee that there are no FW commands in progress on the comm channel
    (for VFs) or wrapped FW commands (on the PF) when SRIOV is active.
    
    We do this by also taking the slave_cmd_mutex when SRIOV is active.
    
    This is especially important when switching from event to polling, since we
    free the command-context array during the switch.  If there are FW commands
    in progress (e.g., waiting for a completion event), the completion event
    handler will access freed memory.
    
    Since the decision to use comm_wait or comm_poll is taken before grabbing
    the event_sem/poll_sem in mlx4_comm_cmd_wait/poll, we must take the
    slave_cmd_mutex as well (to guarantee that the decision to use events or
    polling and the call to the appropriate cmd function are atomic).
    
    Fixes: a7e1f04905e5 ("net/mlx4_core: Fix deadlock when switching between polling and event fw commands")
    Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
    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 22768ca28f896276db1519bd5cf384dcd3cd0db2
Author: Jack Morgenstein <jackm@dev.mellanox.co.il>
Date:   Tue Mar 12 17:05:47 2019 +0200

    net/mlx4_core: Fix reset flow when in command polling mode
    
    [ Upstream commit e15ce4b8d11227007577e6dc1364d288b8874fbe ]
    
    As part of unloading a device, the driver switches from
    FW command event mode to FW command polling mode.
    
    Part of switching over to polling mode is freeing the command context array
    memory (unfortunately, currently, without NULLing the command context array
    pointer).
    
    The reset flow calls "complete" to complete all outstanding fw commands
    (if we are in event mode). The check for event vs. polling mode here
    is to test if the command context array pointer is NULL.
    
    If the reset flow is activated after the switch to polling mode, it will
    attempt (incorrectly) to complete all the commands in the context array --
    because the pointer was not NULLed when the driver switched over to polling
    mode.
    
    As a result, we have a use-after-free situation, which results in a
    kernel crash.
    
    For example:
    BUG: unable to handle kernel NULL pointer dereference at           (null)
    IP: [<ffffffff876c4a8e>] __wake_up_common+0x2e/0x90
    PGD 0
    Oops: 0000 [#1] SMP
    Modules linked in: netconsole nfsv3 nfs_acl nfs lockd grace ...
    CPU: 2 PID: 940 Comm: kworker/2:3 Kdump: loaded Not tainted 3.10.0-862.el7.x86_64 #1
    Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090006  04/28/2016
    Workqueue: events hv_eject_device_work [pci_hyperv]
    task: ffff8d1734ca0fd0 ti: ffff8d17354bc000 task.ti: ffff8d17354bc000
    RIP: 0010:[<ffffffff876c4a8e>]  [<ffffffff876c4a8e>] __wake_up_common+0x2e/0x90
    RSP: 0018:ffff8d17354bfa38  EFLAGS: 00010082
    RAX: 0000000000000000 RBX: ffff8d17362d42c8 RCX: 0000000000000000
    RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff8d17362d42c8
    RBP: ffff8d17354bfa70 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000298 R11: ffff8d173610e000 R12: ffff8d17362d42d0
    R13: 0000000000000246 R14: 0000000000000000 R15: 0000000000000003
    FS:  0000000000000000(0000) GS:ffff8d1802680000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000000 CR3: 00000000f16d8000 CR4: 00000000001406e0
    Call Trace:
     [<ffffffff876c7adc>] complete+0x3c/0x50
     [<ffffffffc04242f0>] mlx4_cmd_wake_completions+0x70/0x90 [mlx4_core]
     [<ffffffffc041e7b1>] mlx4_enter_error_state+0xe1/0x380 [mlx4_core]
     [<ffffffffc041fa4b>] mlx4_comm_cmd+0x29b/0x360 [mlx4_core]
     [<ffffffffc041ff51>] __mlx4_cmd+0x441/0x920 [mlx4_core]
     [<ffffffff877f62b1>] ? __slab_free+0x81/0x2f0
     [<ffffffff87951384>] ? __radix_tree_lookup+0x84/0xf0
     [<ffffffffc043a8eb>] mlx4_free_mtt_range+0x5b/0xb0 [mlx4_core]
     [<ffffffffc043a957>] mlx4_mtt_cleanup+0x17/0x20 [mlx4_core]
     [<ffffffffc04272c7>] mlx4_free_eq+0xa7/0x1c0 [mlx4_core]
     [<ffffffffc042803e>] mlx4_cleanup_eq_table+0xde/0x130 [mlx4_core]
     [<ffffffffc0433e08>] mlx4_unload_one+0x118/0x300 [mlx4_core]
     [<ffffffffc0434191>] mlx4_remove_one+0x91/0x1f0 [mlx4_core]
    
    The fix is to set the command context array pointer to NULL after freeing
    the array.
    
    Fixes: f5aef5aa3506 ("net/mlx4_core: Activate reset flow upon fatal command cases")
    Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
    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 06c7cd5b40e1fd95f3f6303aa5a505d9bb68c1bb
Author: Eric Dumazet <edumazet@google.com>
Date:   Sun Mar 10 10:36:40 2019 -0700

    vxlan: test dev->flags & IFF_UP before calling gro_cells_receive()
    
    [ Upstream commit 59cbf56fcd98ba2a715b6e97c4e43f773f956393 ]
    
    Same reasons than the ones explained in commit 4179cb5a4c92
    ("vxlan: test dev->flags & IFF_UP before calling netif_rx()")
    
    netif_rx() or gro_cells_receive() must be called under a strict contract.
    
    At device dismantle phase, core networking clears IFF_UP
    and flush_all_backlogs() is called after rcu grace period
    to make sure no incoming packet might be in a cpu backlog
    and still referencing the device.
    
    A similar protocol is used for gro_cells infrastructure, as
    gro_cells_destroy() will be called only after a full rcu
    grace period is observed after IFF_UP has been cleared.
    
    Most drivers call netif_rx() from their interrupt handler,
    and since the interrupts are disabled at device dismantle,
    netif_rx() does not have to check dev->flags & IFF_UP
    
    Virtual drivers do not have this guarantee, and must
    therefore make the check themselves.
    
    Otherwise we risk use-after-free and/or crashes.
    
    Fixes: d342894c5d2f ("vxlan: virtual extensible lan")
    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 1ed2291ca6e2782d507f316abcbcb279828dcab7
Author: Stefano Brivio <sbrivio@redhat.com>
Date:   Fri Mar 8 16:40:57 2019 +0100

    vxlan: Fix GRO cells race condition between receive and link delete
    
    [ Upstream commit ad6c9986bcb627c7c22b8f9e9a934becc27df87c ]
    
    If we receive a packet while deleting a VXLAN device, there's a chance
    vxlan_rcv() is called at the same time as vxlan_dellink(). This is fine,
    except that vxlan_dellink() should never ever touch stuff that's still in
    use, such as the GRO cells list.
    
    Otherwise, vxlan_rcv() crashes while queueing packets via
    gro_cells_receive().
    
    Move the gro_cells_destroy() to vxlan_uninit(), which runs after the RCU
    grace period is elapsed and nothing needs the gro_cells anymore.
    
    This is now done in the same way as commit 8e816df87997 ("geneve: Use GRO
    cells infrastructure.") originally implemented for GENEVE.
    
    Reported-by: Jianlin Shi <jishi@redhat.com>
    Fixes: 58ce31cca1ff ("vxlan: GRO support at tunnel layer")
    Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
    Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
    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 bb73b637993bd77087c0f3e56e86a040f230e435
Author: Guillaume Nault <gnault@redhat.com>
Date:   Fri Mar 8 22:09:47 2019 +0100

    tcp: handle inet_csk_reqsk_queue_add() failures
    
    [  Upstream commit 9d3e1368bb45893a75a5dfb7cd21fdebfa6b47af ]
    
    Commit 7716682cc58e ("tcp/dccp: fix another race at listener
    dismantle") let inet_csk_reqsk_queue_add() fail, and adjusted
    {tcp,dccp}_check_req() accordingly. However, TFO and syncookies
    weren't modified, thus leaking allocated resources on error.
    
    Contrary to tcp_check_req(), in both syncookies and TFO cases,
    we need to drop the request socket. Also, since the child socket is
    created with inet_csk_clone_lock(), we have to unlock it and drop an
    extra reference (->sk_refcount is initially set to 2 and
    inet_csk_reqsk_queue_add() drops only one ref).
    
    For TFO, we also need to revert the work done by tcp_try_fastopen()
    (with reqsk_fastopen_remove()).
    
    Fixes: 7716682cc58e ("tcp/dccp: fix another race at listener dismantle")
    Signed-off-by: Guillaume Nault <gnault@redhat.com>
    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 d51c4c0c1fbc338d1b756d9d9d1ba438534546cd
Author: Christoph Paasch <cpaasch@apple.com>
Date:   Mon Mar 11 11:41:05 2019 -0700

    tcp: Don't access TCP_SKB_CB before initializing it
    
    [ Upstream commit f2feaefdabb0a6253aa020f65e7388f07a9ed47c ]
    
    Since commit eeea10b83a13 ("tcp: add
    tcp_v4_fill_cb()/tcp_v4_restore_cb()"), tcp_vX_fill_cb is only called
    after tcp_filter(). That means, TCP_SKB_CB(skb)->end_seq still points to
    the IP-part of the cb.
    
    We thus should not mock with it, as this can trigger bugs (thanks
    syzkaller):
    [   12.349396] ==================================================================
    [   12.350188] BUG: KASAN: slab-out-of-bounds in ip6_datagram_recv_specific_ctl+0x19b3/0x1a20
    [   12.351035] Read of size 1 at addr ffff88006adbc208 by task test_ip6_datagr/1799
    
    Setting end_seq is actually no more necessary in tcp_filter as it gets
    initialized later on in tcp_vX_fill_cb.
    
    Cc: Eric Dumazet <edumazet@google.com>
    Fixes: eeea10b83a13 ("tcp: add tcp_v4_fill_cb()/tcp_v4_restore_cb()")
    Signed-off-by: Christoph Paasch <cpaasch@apple.com>
    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 a63c7fca080e9bdd3368c9c4ab573c01d03f1332
Author: David Howells <dhowells@redhat.com>
Date:   Sat Mar 9 00:29:58 2019 +0000

    rxrpc: Fix client call queueing, waiting for channel
    
    [ Upstream commit 69ffaebb90369ce08657b5aea4896777b9d6e8fc ]
    
    rxrpc_get_client_conn() adds a new call to the front of the waiting_calls
    queue if the connection it's going to use already exists.  This is bad as
    it allows calls to get starved out.
    
    Fix this by adding to the tail instead.
    
    Also change the other enqueue point in the same function to put it on the
    front (ie. when we have a new connection).  This makes the point that in
    the case of a new connection the new call goes at the front (though it
    doesn't actually matter since the queue should be unoccupied).
    
    Fixes: 45025bceef17 ("rxrpc: Improve management and caching of client connection objects")
    Signed-off-by: David Howells <dhowells@redhat.com>
    Reviewed-by: Marc Dionne <marc.dionne@auristor.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 68588407399ab282872f7d9e85c79a6def785214
Author: Xin Long <lucien.xin@gmail.com>
Date:   Fri Mar 8 14:50:54 2019 +0800

    route: set the deleted fnhe fnhe_daddr to 0 in ip_del_fnhe to fix a race
    
    [ Upstream commit ee60ad219f5c7c4fb2f047f88037770063ef785f ]
    
    The race occurs in __mkroute_output() when 2 threads lookup a dst:
    
      CPU A                 CPU B
      find_exception()
                            find_exception() [fnhe expires]
                            ip_del_fnhe() [fnhe is deleted]
      rt_bind_exception()
    
    In rt_bind_exception() it will bind a deleted fnhe with the new dst, and
    this dst will get no chance to be freed. It causes a dev defcnt leak and
    consecutive dmesg warnings:
    
      unregister_netdevice: waiting for ethX to become free. Usage count = 1
    
    Especially thanks Jon to identify the issue.
    
    This patch fixes it by setting fnhe_daddr to 0 in ip_del_fnhe() to stop
    binding the deleted fnhe with a new dst when checking fnhe's fnhe_daddr
    and daddr in rt_bind_exception().
    
    It works as both ip_del_fnhe() and rt_bind_exception() are protected by
    fnhe_lock and the fhne is freed by kfree_rcu().
    
    Fixes: deed49df7390 ("route: check and remove route cache when we get route")
    Signed-off-by: Jon Maxwell <jmaxwell37@gmail.com>
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Reviewed-by: David Ahern <dsahern@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1a443e2d40e6e278c8f468b835c7f3e21904aa7a
Author: Masaru Nagai <masaru.nagai.vx@renesas.com>
Date:   Thu Mar 7 11:24:47 2019 +0100

    ravb: Decrease TxFIFO depth of Q3 and Q2 to one
    
    [ Upstream commit ae9819e339b451da7a86ab6fe38ecfcb6814e78a ]
    
    Hardware has the CBS (Credit Based Shaper) which affects only Q3
    and Q2. When updating the CBS settings, even if the driver does so
    after waiting for Tx DMA finished, there is a possibility that frame
    data still remains in TxFIFO.
    
    To avoid this, decrease TxFIFO depth of Q3 and Q2 to one.
    
    This patch has been exercised this using netperf TCP_MAERTS, TCP_STREAM
    and UDP_STREAM tests run on an Ebisu board. No performance change was
    detected, outside of noise in the tests, both in terms of throughput and
    CPU utilisation.
    
    Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
    Signed-off-by: Masaru Nagai <masaru.nagai.vx@renesas.com>
    Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
    [simon: updated changelog]
    Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eff9b85fe90978a740f053e95441ee937463f25e
Author: Xin Long <lucien.xin@gmail.com>
Date:   Wed Mar 13 17:00:48 2019 +0800

    pptp: dst_release sk_dst_cache in pptp_sock_destruct
    
    [ Upstream commit 9417d81f4f8adfe20a12dd1fadf73a618cbd945d ]
    
    sk_setup_caps() is called to set sk->sk_dst_cache in pptp_connect,
    so we have to dst_release(sk->sk_dst_cache) in pptp_sock_destruct,
    otherwise, the dst refcnt will leak.
    
    It can be reproduced by this syz log:
    
      r1 = socket$pptp(0x18, 0x1, 0x2)
      bind$pptp(r1, &(0x7f0000000100)={0x18, 0x2, {0x0, @local}}, 0x1e)
      connect$pptp(r1, &(0x7f0000000000)={0x18, 0x2, {0x3, @remote}}, 0x1e)
    
    Consecutive dmesg warnings will occur:
    
      unregister_netdevice: waiting for lo to become free. Usage count = 1
    
    v1->v2:
      - use rcu_dereference_protected() instead of rcu_dereference_check(),
        as suggested by Eric.
    
    Fixes: 00959ade36ac ("PPTP: PPP over IPv4 (Point-to-Point Tunneling Protocol)")
    Reported-by: Xiumei Mu <xmu@redhat.com>
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 91820c10ea6149c9af32be20d7cfda3375ab6529
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Mar 11 13:48:44 2019 -0700

    net/x25: reset state in x25_connect()
    
    [ Upstream commit ee74d0bd4325efb41e38affe5955f920ed973f23 ]
    
    In case x25_connect() fails and frees the socket neighbour,
    we also need to undo the change done to x25->state.
    
    Before my last bug fix, we had use-after-free so this
    patch fixes a latent bug.
    
    syzbot report :
    
    kasan: CONFIG_KASAN_INLINE enabled
    kasan: GPF could be caused by NULL-ptr deref or user memory access
    general protection fault: 0000 [#1] PREEMPT SMP KASAN
    CPU: 1 PID: 16137 Comm: syz-executor.1 Not tainted 5.0.0+ #117
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    RIP: 0010:x25_write_internal+0x1e8/0xdf0 net/x25/x25_subr.c:173
    Code: 00 40 88 b5 e0 fe ff ff 0f 85 01 0b 00 00 48 8b 8b 80 04 00 00 48 ba 00 00 00 00 00 fc ff df 48 8d 79 1c 48 89 fe 48 c1 ee 03 <0f> b6 34 16 48 89 fa 83 e2 07 83 c2 03 40 38 f2 7c 09 40 84 f6 0f
    RSP: 0018:ffff888076717a08 EFLAGS: 00010207
    RAX: ffff88805f2f2292 RBX: ffff8880a0ae6000 RCX: 0000000000000000
    kobject: 'loop5' (0000000018d0d0ee): kobject_uevent_env
    RDX: dffffc0000000000 RSI: 0000000000000003 RDI: 000000000000001c
    RBP: ffff888076717b40 R08: ffff8880950e0580 R09: ffffed100be5e46d
    R10: ffffed100be5e46c R11: ffff88805f2f2363 R12: ffff888065579840
    kobject: 'loop5' (0000000018d0d0ee): fill_kobj_path: path = '/devices/virtual/block/loop5'
    R13: 1ffff1100ece2f47 R14: 0000000000000013 R15: 0000000000000013
    FS:  00007fb88cf43700(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f9a42a41028 CR3: 0000000087a67000 CR4: 00000000001406e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     x25_release+0xd0/0x340 net/x25/af_x25.c:658
     __sock_release+0xd3/0x2b0 net/socket.c:579
     sock_close+0x1b/0x30 net/socket.c:1162
     __fput+0x2df/0x8d0 fs/file_table.c:278
     ____fput+0x16/0x20 fs/file_table.c:309
     task_work_run+0x14a/0x1c0 kernel/task_work.c:113
     get_signal+0x1961/0x1d50 kernel/signal.c:2388
     do_signal+0x87/0x1940 arch/x86/kernel/signal.c:816
     exit_to_usermode_loop+0x244/0x2c0 arch/x86/entry/common.c:162
     prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
     syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
     do_syscall_64+0x52d/0x610 arch/x86/entry/common.c:293
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    RIP: 0033:0x457f29
    Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
    RSP: 002b:00007fb88cf42c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
    RAX: fffffffffffffe00 RBX: 0000000000000003 RCX: 0000000000457f29
    RDX: 0000000000000012 RSI: 0000000020000080 RDI: 0000000000000004
    RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 00007fb88cf436d4
    R13: 00000000004be462 R14: 00000000004cec98 R15: 00000000ffffffff
    Modules linked in:
    
    Fixes: 95d6ebd53c79 ("net/x25: fix use-after-free in x25_device_event()")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: andrew hendry <andrew.hendry@gmail.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 ffd4228bdf861b3a206738854f171eef85093c54
Author: Eric Dumazet <edumazet@google.com>
Date:   Sun Mar 10 09:07:14 2019 -0700

    net/x25: fix use-after-free in x25_device_event()
    
    [ Upstream commit 95d6ebd53c79522bf9502dbc7e89e0d63f94dae4 ]
    
    In case of failure x25_connect() does a x25_neigh_put(x25->neighbour)
    but forgets to clear x25->neighbour pointer, thus triggering use-after-free.
    
    Since the socket is visible in x25_list, we need to hold x25_list_lock
    to protect the operation.
    
    syzbot report :
    
    BUG: KASAN: use-after-free in x25_kill_by_device net/x25/af_x25.c:217 [inline]
    BUG: KASAN: use-after-free in x25_device_event+0x296/0x2b0 net/x25/af_x25.c:252
    Read of size 8 at addr ffff8880a030edd0 by task syz-executor003/7854
    
    CPU: 0 PID: 7854 Comm: syz-executor003 Not tainted 5.0.0+ #97
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Call Trace:
     __dump_stack lib/dump_stack.c:77 [inline]
     dump_stack+0x172/0x1f0 lib/dump_stack.c:113
     print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
     kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
     __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:135
     x25_kill_by_device net/x25/af_x25.c:217 [inline]
     x25_device_event+0x296/0x2b0 net/x25/af_x25.c:252
     notifier_call_chain+0xc7/0x240 kernel/notifier.c:93
     __raw_notifier_call_chain kernel/notifier.c:394 [inline]
     raw_notifier_call_chain+0x2e/0x40 kernel/notifier.c:401
     call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1739
     call_netdevice_notifiers_extack net/core/dev.c:1751 [inline]
     call_netdevice_notifiers net/core/dev.c:1765 [inline]
     __dev_notify_flags+0x1e9/0x2c0 net/core/dev.c:7607
     dev_change_flags+0x10d/0x170 net/core/dev.c:7643
     dev_ifsioc+0x2b0/0x940 net/core/dev_ioctl.c:237
     dev_ioctl+0x1b8/0xc70 net/core/dev_ioctl.c:488
     sock_do_ioctl+0x1bd/0x300 net/socket.c:995
     sock_ioctl+0x32b/0x610 net/socket.c:1096
     vfs_ioctl fs/ioctl.c:46 [inline]
     file_ioctl fs/ioctl.c:509 [inline]
     do_vfs_ioctl+0xd6e/0x1390 fs/ioctl.c:696
     ksys_ioctl+0xab/0xd0 fs/ioctl.c:713
     __do_sys_ioctl fs/ioctl.c:720 [inline]
     __se_sys_ioctl fs/ioctl.c:718 [inline]
     __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718
     do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    RIP: 0033:0x4467c9
    Code: e8 0c e8 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 5b 07 fc ff c3 66 2e 0f 1f 84 00 00 00 00
    RSP: 002b:00007fdbea222d98 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
    RAX: ffffffffffffffda RBX: 00000000006dbc58 RCX: 00000000004467c9
    RDX: 0000000020000340 RSI: 0000000000008914 RDI: 0000000000000003
    RBP: 00000000006dbc50 R08: 00007fdbea223700 R09: 0000000000000000
    R10: 00007fdbea223700 R11: 0000000000000246 R12: 00000000006dbc5c
    R13: 6000030030626669 R14: 0000000000000000 R15: 0000000030626669
    
    Allocated by task 7843:
     save_stack+0x45/0xd0 mm/kasan/common.c:73
     set_track mm/kasan/common.c:85 [inline]
     __kasan_kmalloc mm/kasan/common.c:495 [inline]
     __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:468
     kasan_kmalloc+0x9/0x10 mm/kasan/common.c:509
     kmem_cache_alloc_trace+0x151/0x760 mm/slab.c:3615
     kmalloc include/linux/slab.h:545 [inline]
     x25_link_device_up+0x46/0x3f0 net/x25/x25_link.c:249
     x25_device_event+0x116/0x2b0 net/x25/af_x25.c:242
     notifier_call_chain+0xc7/0x240 kernel/notifier.c:93
     __raw_notifier_call_chain kernel/notifier.c:394 [inline]
     raw_notifier_call_chain+0x2e/0x40 kernel/notifier.c:401
     call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1739
     call_netdevice_notifiers_extack net/core/dev.c:1751 [inline]
     call_netdevice_notifiers net/core/dev.c:1765 [inline]
     __dev_notify_flags+0x121/0x2c0 net/core/dev.c:7605
     dev_change_flags+0x10d/0x170 net/core/dev.c:7643
     dev_ifsioc+0x2b0/0x940 net/core/dev_ioctl.c:237
     dev_ioctl+0x1b8/0xc70 net/core/dev_ioctl.c:488
     sock_do_ioctl+0x1bd/0x300 net/socket.c:995
     sock_ioctl+0x32b/0x610 net/socket.c:1096
     vfs_ioctl fs/ioctl.c:46 [inline]
     file_ioctl fs/ioctl.c:509 [inline]
     do_vfs_ioctl+0xd6e/0x1390 fs/ioctl.c:696
     ksys_ioctl+0xab/0xd0 fs/ioctl.c:713
     __do_sys_ioctl fs/ioctl.c:720 [inline]
     __se_sys_ioctl fs/ioctl.c:718 [inline]
     __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718
     do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
    Freed by task 7865:
     save_stack+0x45/0xd0 mm/kasan/common.c:73
     set_track mm/kasan/common.c:85 [inline]
     __kasan_slab_free+0x102/0x150 mm/kasan/common.c:457
     kasan_slab_free+0xe/0x10 mm/kasan/common.c:465
     __cache_free mm/slab.c:3494 [inline]
     kfree+0xcf/0x230 mm/slab.c:3811
     x25_neigh_put include/net/x25.h:253 [inline]
     x25_connect+0x8d8/0xde0 net/x25/af_x25.c:824
     __sys_connect+0x266/0x330 net/socket.c:1685
     __do_sys_connect net/socket.c:1696 [inline]
     __se_sys_connect net/socket.c:1693 [inline]
     __x64_sys_connect+0x73/0xb0 net/socket.c:1693
     do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
    The buggy address belongs to the object at ffff8880a030edc0
     which belongs to the cache kmalloc-256 of size 256
    The buggy address is located 16 bytes inside of
     256-byte region [ffff8880a030edc0, ffff8880a030eec0)
    The buggy address belongs to the page:
    page:ffffea000280c380 count:1 mapcount:0 mapping:ffff88812c3f07c0 index:0x0
    flags: 0x1fffc0000000200(slab)
    raw: 01fffc0000000200 ffffea0002806788 ffffea00027f0188 ffff88812c3f07c0
    raw: 0000000000000000 ffff8880a030e000 000000010000000c 0000000000000000
    page dumped because: kasan: bad access detected
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot+04babcefcd396fabec37@syzkaller.appspotmail.com
    Cc: andrew hendry <andrew.hendry@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a68ac22fc4366b37d9271a5300da59bfeb448cd3
Author: Miaohe Lin <linmiaohe@huawei.com>
Date:   Mon Mar 11 16:29:32 2019 +0800

    net: sit: fix UBSAN Undefined behaviour in check_6rd
    
    [ Upstream commit a843dc4ebaecd15fca1f4d35a97210f72ea1473b ]
    
    In func check_6rd,tunnel->ip6rd.relay_prefixlen may equal to
    32,so UBSAN complain about it.
    
    UBSAN: Undefined behaviour in net/ipv6/sit.c:781:47
    shift exponent 32 is too large for 32-bit type 'unsigned int'
    CPU: 6 PID: 20036 Comm: syz-executor.0 Not tainted 4.19.27 #2
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1
    04/01/2014
    Call Trace:
    __dump_stack lib/dump_stack.c:77 [inline]
    dump_stack+0xca/0x13e lib/dump_stack.c:113
    ubsan_epilogue+0xe/0x81 lib/ubsan.c:159
    __ubsan_handle_shift_out_of_bounds+0x293/0x2e8 lib/ubsan.c:425
    check_6rd.constprop.9+0x433/0x4e0 net/ipv6/sit.c:781
    try_6rd net/ipv6/sit.c:806 [inline]
    ipip6_tunnel_xmit net/ipv6/sit.c:866 [inline]
    sit_tunnel_xmit+0x141c/0x2720 net/ipv6/sit.c:1033
    __netdev_start_xmit include/linux/netdevice.h:4300 [inline]
    netdev_start_xmit include/linux/netdevice.h:4309 [inline]
    xmit_one net/core/dev.c:3243 [inline]
    dev_hard_start_xmit+0x17c/0x780 net/core/dev.c:3259
    __dev_queue_xmit+0x1656/0x2500 net/core/dev.c:3829
    neigh_output include/net/neighbour.h:501 [inline]
    ip6_finish_output2+0xa36/0x2290 net/ipv6/ip6_output.c:120
    ip6_finish_output+0x3e7/0xa20 net/ipv6/ip6_output.c:154
    NF_HOOK_COND include/linux/netfilter.h:278 [inline]
    ip6_output+0x1e2/0x720 net/ipv6/ip6_output.c:171
    dst_output include/net/dst.h:444 [inline]
    ip6_local_out+0x99/0x170 net/ipv6/output_core.c:176
    ip6_send_skb+0x9d/0x2f0 net/ipv6/ip6_output.c:1697
    ip6_push_pending_frames+0xc0/0x100 net/ipv6/ip6_output.c:1717
    rawv6_push_pending_frames net/ipv6/raw.c:616 [inline]
    rawv6_sendmsg+0x2435/0x3530 net/ipv6/raw.c:946
    inet_sendmsg+0xf8/0x5c0 net/ipv4/af_inet.c:798
    sock_sendmsg_nosec net/socket.c:621 [inline]
    sock_sendmsg+0xc8/0x110 net/socket.c:631
    ___sys_sendmsg+0x6cf/0x890 net/socket.c:2114
    __sys_sendmsg+0xf0/0x1b0 net/socket.c:2152
    do_syscall_64+0xc8/0x580 arch/x86/entry/common.c:290
    entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
    Signed-off-by: linmiaohe <linmiaohe@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 60001460c89d2c92fe53e8b1865a1ddec7fb01eb
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Mar 7 09:36:33 2019 -0800

    net/hsr: fix possible crash in add_timer()
    
    [ Upstream commit 1e027960edfaa6a43f9ca31081729b716598112b ]
    
    syzbot found another add_timer() issue, this time in net/hsr [1]
    
    Let's use mod_timer() which is safe.
    
    [1]
    kernel BUG at kernel/time/timer.c:1136!
    invalid opcode: 0000 [#1] PREEMPT SMP KASAN
    CPU: 0 PID: 15909 Comm: syz-executor.3 Not tainted 5.0.0+ #97
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    kobject: 'loop2' (00000000f5629718): kobject_uevent_env
    RIP: 0010:add_timer kernel/time/timer.c:1136 [inline]
    RIP: 0010:add_timer+0x654/0xbe0 kernel/time/timer.c:1134
    Code: 0f 94 c5 31 ff 44 89 ee e8 09 61 0f 00 45 84 ed 0f 84 77 fd ff ff e8 bb 5f 0f 00 e8 07 10 a0 ff e9 68 fd ff ff e8 ac 5f 0f 00 <0f> 0b e8 a5 5f 0f 00 0f 0b e8 9e 5f 0f 00 4c 89 b5 58 ff ff ff e9
    RSP: 0018:ffff8880656eeca0 EFLAGS: 00010246
    kobject: 'loop2' (00000000f5629718): fill_kobj_path: path = '/devices/virtual/block/loop2'
    RAX: 0000000000040000 RBX: 1ffff1100caddd9a RCX: ffffc9000c436000
    RDX: 0000000000040000 RSI: ffffffff816056c4 RDI: ffff88806a2f6cc8
    RBP: ffff8880656eed58 R08: ffff888067f4a300 R09: ffff888067f4abc8
    R10: 0000000000000000 R11: 0000000000000000 R12: ffff88806a2f6cc0
    R13: dffffc0000000000 R14: 0000000000000001 R15: ffff8880656eed30
    FS:  00007fc2019bf700(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000738000 CR3: 0000000067e8e000 CR4: 00000000001406f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     hsr_check_announce net/hsr/hsr_device.c:99 [inline]
     hsr_check_carrier_and_operstate+0x567/0x6f0 net/hsr/hsr_device.c:120
     hsr_netdev_notify+0x297/0xa00 net/hsr/hsr_main.c:51
     notifier_call_chain+0xc7/0x240 kernel/notifier.c:93
     __raw_notifier_call_chain kernel/notifier.c:394 [inline]
     raw_notifier_call_chain+0x2e/0x40 kernel/notifier.c:401
     call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1739
     call_netdevice_notifiers_extack net/core/dev.c:1751 [inline]
     call_netdevice_notifiers net/core/dev.c:1765 [inline]
     dev_open net/core/dev.c:1436 [inline]
     dev_open+0x143/0x160 net/core/dev.c:1424
     team_port_add drivers/net/team/team.c:1203 [inline]
     team_add_slave+0xa07/0x15d0 drivers/net/team/team.c:1933
     do_set_master net/core/rtnetlink.c:2358 [inline]
     do_set_master+0x1d4/0x230 net/core/rtnetlink.c:2332
     do_setlink+0x966/0x3510 net/core/rtnetlink.c:2493
     rtnl_setlink+0x271/0x3b0 net/core/rtnetlink.c:2747
     rtnetlink_rcv_msg+0x465/0xb00 net/core/rtnetlink.c:5192
     netlink_rcv_skb+0x17a/0x460 net/netlink/af_netlink.c:2485
     rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5210
     netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
     netlink_unicast+0x536/0x720 net/netlink/af_netlink.c:1336
     netlink_sendmsg+0x8ae/0xd70 net/netlink/af_netlink.c:1925
     sock_sendmsg_nosec net/socket.c:622 [inline]
     sock_sendmsg+0xdd/0x130 net/socket.c:632
     sock_write_iter+0x27c/0x3e0 net/socket.c:923
     call_write_iter include/linux/fs.h:1869 [inline]
     do_iter_readv_writev+0x5e0/0x8e0 fs/read_write.c:680
     do_iter_write fs/read_write.c:956 [inline]
     do_iter_write+0x184/0x610 fs/read_write.c:937
     vfs_writev+0x1b3/0x2f0 fs/read_write.c:1001
     do_writev+0xf6/0x290 fs/read_write.c:1036
     __do_sys_writev fs/read_write.c:1109 [inline]
     __se_sys_writev fs/read_write.c:1106 [inline]
     __x64_sys_writev+0x75/0xb0 fs/read_write.c:1106
     do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    RIP: 0033:0x457f29
    Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
    RSP: 002b:00007fc2019bec78 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
    RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457f29
    RDX: 0000000000000001 RSI: 00000000200000c0 RDI: 0000000000000003
    RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 00007fc2019bf6d4
    R13: 00000000004c4a60 R14: 00000000004dd218 R15: 00000000ffffffff
    
    Fixes: f421436a591d ("net/hsr: Add support for the High-availability Seamless Redundancy protocol (HSRv0)")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Cc: Arvid Brodin <arvid.brodin@alten.se>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1aa1e0a3f6dde5c37bb5d6a9121847b95b255c1f
Author: Mao Wenan <maowenan@huawei.com>
Date:   Wed Mar 6 22:45:01 2019 +0800

    net: hsr: fix memory leak in hsr_dev_finalize()
    
    [ Upstream commit 6caabe7f197d3466d238f70915d65301f1716626 ]
    
    If hsr_add_port(hsr, hsr_dev, HSR_PT_MASTER) failed to
    add port, it directly returns res and forgets to free the node
    that allocated in hsr_create_self_node(), and forgets to delete
    the node->mac_list linked in hsr->self_node_db.
    
    BUG: memory leak
    unreferenced object 0xffff8881cfa0c780 (size 64):
      comm "syz-executor.0", pid 2077, jiffies 4294717969 (age 2415.377s)
      hex dump (first 32 bytes):
        e0 c7 a0 cf 81 88 ff ff 00 02 00 00 00 00 ad de  ................
        00 e6 49 cd 81 88 ff ff c0 9b 87 d0 81 88 ff ff  ..I.............
      backtrace:
        [<00000000e2ff5070>] hsr_dev_finalize+0x736/0x960 [hsr]
        [<000000003ed2e597>] hsr_newlink+0x2b2/0x3e0 [hsr]
        [<000000003fa8c6b6>] __rtnl_newlink+0xf1f/0x1600 net/core/rtnetlink.c:3182
        [<000000001247a7ad>] rtnl_newlink+0x66/0x90 net/core/rtnetlink.c:3240
        [<00000000e7d1b61d>] rtnetlink_rcv_msg+0x54e/0xb90 net/core/rtnetlink.c:5130
        [<000000005556bd3a>] netlink_rcv_skb+0x129/0x340 net/netlink/af_netlink.c:2477
        [<00000000741d5ee6>] netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
        [<00000000741d5ee6>] netlink_unicast+0x49a/0x650 net/netlink/af_netlink.c:1336
        [<000000009d56f9b7>] netlink_sendmsg+0x88b/0xdf0 net/netlink/af_netlink.c:1917
        [<0000000046b35c59>] sock_sendmsg_nosec net/socket.c:621 [inline]
        [<0000000046b35c59>] sock_sendmsg+0xc3/0x100 net/socket.c:631
        [<00000000d208adc9>] __sys_sendto+0x33e/0x560 net/socket.c:1786
        [<00000000b582837a>] __do_sys_sendto net/socket.c:1798 [inline]
        [<00000000b582837a>] __se_sys_sendto net/socket.c:1794 [inline]
        [<00000000b582837a>] __x64_sys_sendto+0xdd/0x1b0 net/socket.c:1794
        [<00000000c866801d>] do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
        [<00000000fea382d9>] entry_SYSCALL_64_after_hwframe+0x49/0xbe
        [<00000000e01dacb3>] 0xffffffffffffffff
    
    Fixes: c5a759117210 ("net/hsr: Use list_head (and rcu) instead of array for slave devices.")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Mao Wenan <maowenan@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit af6822a7915acf7eacd84cabf4a1c9013345aed0
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Mar 12 06:50:11 2019 -0700

    l2tp: fix infoleak in l2tp_ip6_recvmsg()
    
    [ Upstream commit 163d1c3d6f17556ed3c340d3789ea93be95d6c28 ]
    
    Back in 2013 Hannes took care of most of such leaks in commit
    bceaa90240b6 ("inet: prevent leakage of uninitialized memory to user in recv syscalls")
    
    But the bug in l2tp_ip6_recvmsg() has not been fixed.
    
    syzbot report :
    
    BUG: KMSAN: kernel-infoleak in _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
    CPU: 1 PID: 10996 Comm: syz-executor362 Not tainted 5.0.0+ #11
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Call Trace:
     __dump_stack lib/dump_stack.c:77 [inline]
     dump_stack+0x173/0x1d0 lib/dump_stack.c:113
     kmsan_report+0x12e/0x2a0 mm/kmsan/kmsan.c:600
     kmsan_internal_check_memory+0x9f4/0xb10 mm/kmsan/kmsan.c:694
     kmsan_copy_to_user+0xab/0xc0 mm/kmsan/kmsan_hooks.c:601
     _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
     copy_to_user include/linux/uaccess.h:174 [inline]
     move_addr_to_user+0x311/0x570 net/socket.c:227
     ___sys_recvmsg+0xb65/0x1310 net/socket.c:2283
     do_recvmmsg+0x646/0x10c0 net/socket.c:2390
     __sys_recvmmsg net/socket.c:2469 [inline]
     __do_sys_recvmmsg net/socket.c:2492 [inline]
     __se_sys_recvmmsg+0x1d1/0x350 net/socket.c:2485
     __x64_sys_recvmmsg+0x62/0x80 net/socket.c:2485
     do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
     entry_SYSCALL_64_after_hwframe+0x63/0xe7
    RIP: 0033:0x445819
    Code: e8 6c b6 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 2b 12 fc ff c3 66 2e 0f 1f 84 00 00 00 00
    RSP: 002b:00007f64453eddb8 EFLAGS: 00000246 ORIG_RAX: 000000000000012b
    RAX: ffffffffffffffda RBX: 00000000006dac28 RCX: 0000000000445819
    RDX: 0000000000000005 RSI: 0000000020002f80 RDI: 0000000000000003
    RBP: 00000000006dac20 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 00000000006dac2c
    R13: 00007ffeba8f87af R14: 00007f64453ee9c0 R15: 20c49ba5e353f7cf
    
    Local variable description: ----addr@___sys_recvmsg
    Variable was created at:
     ___sys_recvmsg+0xf6/0x1310 net/socket.c:2244
     do_recvmmsg+0x646/0x10c0 net/socket.c:2390
    
    Bytes 0-31 of 32 are uninitialized
    Memory access of size 32 starts at ffff8880ae62fbb0
    Data copied to user address 0000000020000000
    
    Fixes: a32e0eec7042 ("l2tp: introduce L2TPv3 IP encapsulation support for IPv6")
    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 c8c6b846249b8cfe825d86e71df9cbbea0d9c01c
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Wed Mar 6 10:42:53 2019 +0100

    ipv4/route: fail early when inet dev is missing
    
    [ Upstream commit 22c74764aa2943ecdf9f07c900d8a9c8ba6c9265 ]
    
    If a non local multicast packet reaches ip_route_input_rcu() while
    the ingress device IPv4 private data (in_dev) is NULL, we end up
    doing a NULL pointer dereference in IN_DEV_MFORWARD().
    
    Since the later call to ip_route_input_mc() is going to fail if
    !in_dev, we can fail early in such scenario and avoid the dangerous
    code path.
    
    v1 -> v2:
     - clarified the commit message, no code changes
    
    Reported-by: Tianhao Zhao <tizhao@redhat.com>
    Fixes: e58e41596811 ("net: Enable support for VRF with ipv4 multicast")
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: David Ahern <dsahern@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 136e109797f3e9e61076a401eb1353362be592b4
Author: Eric Dumazet <edumazet@google.com>
Date:   Sun Mar 10 10:39:37 2019 -0700

    gro_cells: make sure device is up in gro_cells_receive()
    
    [ Upstream commit 2a5ff07a0eb945f291e361aa6f6becca8340ba46 ]
    
    We keep receiving syzbot reports [1] that show that tunnels do not play
    the rcu/IFF_UP rules properly.
    
    At device dismantle phase, gro_cells_destroy() will be called
    only after a full rcu grace period is observed after IFF_UP
    has been cleared.
    
    This means that IFF_UP needs to be tested before queueing packets
    into netif_rx() or gro_cells.
    
    This patch implements the test in gro_cells_receive() because
    too many callers do not seem to bother enough.
    
    [1]
    BUG: unable to handle kernel paging request at fffff4ca0b9ffffe
    PGD 0 P4D 0
    Oops: 0000 [#1] PREEMPT SMP KASAN
    CPU: 0 PID: 21 Comm: kworker/u4:1 Not tainted 5.0.0+ #97
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Workqueue: netns cleanup_net
    RIP: 0010:__skb_unlink include/linux/skbuff.h:1929 [inline]
    RIP: 0010:__skb_dequeue include/linux/skbuff.h:1945 [inline]
    RIP: 0010:__skb_queue_purge include/linux/skbuff.h:2656 [inline]
    RIP: 0010:gro_cells_destroy net/core/gro_cells.c:89 [inline]
    RIP: 0010:gro_cells_destroy+0x19d/0x360 net/core/gro_cells.c:78
    Code: 03 42 80 3c 20 00 0f 85 53 01 00 00 48 8d 7a 08 49 8b 47 08 49 c7 07 00 00 00 00 48 89 f9 49 c7 47 08 00 00 00 00 48 c1 e9 03 <42> 80 3c 21 00 0f 85 10 01 00 00 48 89 c1 48 89 42 08 48 c1 e9 03
    RSP: 0018:ffff8880aa3f79a8 EFLAGS: 00010a02
    RAX: 00ffffffffffffe8 RBX: ffffe8ffffc64b70 RCX: 1ffff8ca0b9ffffe
    RDX: ffffc6505cffffe8 RSI: ffffffff858410ca RDI: ffffc6505cfffff0
    RBP: ffff8880aa3f7a08 R08: ffff8880aa3e8580 R09: fffffbfff1263645
    R10: fffffbfff1263644 R11: ffffffff8931b223 R12: dffffc0000000000
    R13: 0000000000000000 R14: ffffe8ffffc64b80 R15: ffffe8ffffc64b75
    kobject: 'loop2' (000000004bd7d84a): kobject_uevent_env
    FS:  0000000000000000(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: fffff4ca0b9ffffe CR3: 0000000094941000 CR4: 00000000001406f0
    Call Trace:
    kobject: 'loop2' (000000004bd7d84a): fill_kobj_path: path = '/devices/virtual/block/loop2'
     ip_tunnel_dev_free+0x19/0x60 net/ipv4/ip_tunnel.c:1010
     netdev_run_todo+0x51c/0x7d0 net/core/dev.c:8970
     rtnl_unlock+0xe/0x10 net/core/rtnetlink.c:116
     ip_tunnel_delete_nets+0x423/0x5f0 net/ipv4/ip_tunnel.c:1124
     vti_exit_batch_net+0x23/0x30 net/ipv4/ip_vti.c:495
     ops_exit_list.isra.0+0x105/0x160 net/core/net_namespace.c:156
     cleanup_net+0x3fb/0x960 net/core/net_namespace.c:551
     process_one_work+0x98e/0x1790 kernel/workqueue.c:2173
     worker_thread+0x98/0xe40 kernel/workqueue.c:2319
     kthread+0x357/0x430 kernel/kthread.c:246
     ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
    Modules linked in:
    CR2: fffff4ca0b9ffffe
       [ end trace 513fc9c1338d1cb3 ]
    RIP: 0010:__skb_unlink include/linux/skbuff.h:1929 [inline]
    RIP: 0010:__skb_dequeue include/linux/skbuff.h:1945 [inline]
    RIP: 0010:__skb_queue_purge include/linux/skbuff.h:2656 [inline]
    RIP: 0010:gro_cells_destroy net/core/gro_cells.c:89 [inline]
    RIP: 0010:gro_cells_destroy+0x19d/0x360 net/core/gro_cells.c:78
    Code: 03 42 80 3c 20 00 0f 85 53 01 00 00 48 8d 7a 08 49 8b 47 08 49 c7 07 00 00 00 00 48 89 f9 49 c7 47 08 00 00 00 00 48 c1 e9 03 <42> 80 3c 21 00 0f 85 10 01 00 00 48 89 c1 48 89 42 08 48 c1 e9 03
    RSP: 0018:ffff8880aa3f79a8 EFLAGS: 00010a02
    RAX: 00ffffffffffffe8 RBX: ffffe8ffffc64b70 RCX: 1ffff8ca0b9ffffe
    RDX: ffffc6505cffffe8 RSI: ffffffff858410ca RDI: ffffc6505cfffff0
    RBP: ffff8880aa3f7a08 R08: ffff8880aa3e8580 R09: fffffbfff1263645
    R10: fffffbfff1263644 R11: ffffffff8931b223 R12: dffffc0000000000
    kobject: 'loop3' (00000000e4ee57a6): kobject_uevent_env
    R13: 0000000000000000 R14: ffffe8ffffc64b80 R15: ffffe8ffffc64b75
    FS:  0000000000000000(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: fffff4ca0b9ffffe CR3: 0000000094941000 CR4: 00000000001406f0
    
    Fixes: c9e6bc644e55 ("net: add gro_cells infrastructure")
    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 1ce1eb5fb1daa64eba1dc1d58b13fb3b327be8ed
Author: Wang Nan <wangnan0@huawei.com>
Date:   Wed Dec 6 01:50:40 2017 +0000

    perf tools: Fix compile error with libunwind x86
    
    commit 44df1afdb174fd6038e419f80efd914c0b5f2f85 upstream.
    
    Fix a compile error:
    
     ...
       CC       util/libunwind/x86_32.o
     In file included from util/libunwind/x86_32.c:33:0:
     util/libunwind/../../arch/x86/util/unwind-libunwind.c: In function 'libunwind__x86_reg_id':
     util/libunwind/../../arch/x86/util/unwind-libunwind.c:110:11: error: 'EINVAL' undeclared (first use in this function)
        return -EINVAL;
                ^
     util/libunwind/../../arch/x86/util/unwind-libunwind.c:110:11: note: each undeclared identifier is reported only once for each function it appears in
     mv: cannot stat 'util/libunwind/.x86_32.o.tmp': No such file or directory
     make[4]: *** [util/libunwind/x86_32.o] Error 1
     make[3]: *** [util] Error 2
     make[2]: *** [libperf-in.o] Error 2
     make[1]: *** [sub-make] Error 2
     make: *** [all] Error 2
    
    It happens when libunwind-x86 feature is detected.
    
    Signed-off-by: Wang Nan <wangnan0@huawei.com>
    Link: http://lkml.kernel.org/r/20171206015040.114574-1-wangnan0@huawei.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Daniel Díaz <daniel.diaz@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 785eb09ceb61a9c7d2a6c72e033bef04a89f1778
Author: Erik Schmauss <erik.schmauss@intel.com>
Date:   Fri Aug 10 14:43:02 2018 -0700

    ACPICA: Reference Counts: increase max to 0x4000 for large servers
    
    commit 8b23570ab001c1982c8a068cde468ff067255314 upstream.
    
    Increase the reference count limit to 0x4000 as the current one is
    not sufficient for some large server systems.
    
    Reviewed-by: Dimitri Sivanich <dimitri.sivanich@hpe.com>
    Tested-by: Russ Anderson <russ.anderson@hpe.com>
    Reported-by: Mike Travis <mike.travis@hpe.com>
    Signed-off-by: Mike Travis <mike.travis@hpe.com>
    Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
    [ rjw: Changelog ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Cc: Frank van der Linden <fllinden@amazon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>