1. 28 Feb, 2018 16 commits
    • Thinh Nguyen's avatar
      usb: dwc3: gadget: Set maxpacket size for ep0 IN · 2421986b
      Thinh Nguyen authored
      commit 61800263 upstream.
      
      There are 2 control endpoint structures for DWC3. However, the driver
      only updates the OUT direction control endpoint structure during
      ConnectDone event. DWC3 driver needs to update the endpoint max packet
      size for control IN endpoint as well. If the max packet size is not
      properly set, then the driver will incorrectly calculate the data
      transfer size and fail to send ZLP for HS/FS 3-stage control read
      transfer.
      
      The fix is simply to update the max packet size for the ep0 IN direction
      during ConnectDone event.
      
      Cc: stable@vger.kernel.org
      Fixes: 72246da4 ("usb: Introduce DesignWare USB3 DRD Driver")
      Signed-off-by: default avatarThinh Nguyen <thinhn@synopsys.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2421986b
    • Kai-Heng Feng's avatar
      drm/edid: Add 6 bpc quirk for CPT panel in Asus UX303LA · 5b7ed414
      Kai-Heng Feng authored
      commit 06998a75 upstream.
      
      Similar to commit e10aec65 ("drm/edid: Add 6 bpc quirk for display
      AEO model 0."), the EDID reports "DFP 1.x compliant TMDS" but it support
      6bpc instead of 8 bpc.
      
      Hence, use 6 bpc quirk for this panel.
      
      Fixes: 196f954e ("drm/i915/dp: Revert "drm/i915/dp: fall back to 18 bpp when sink capability is unknown"")
      BugLink: https://bugs.launchpad.net/bugs/1749420Signed-off-by: default avatarKai-Heng Feng <kai.heng.feng@canonical.com>
      Reviewed-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Cc: <stable@vger.kernel.org> # v4.8+
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180218085359.7817-1-kai.heng.feng@canonical.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5b7ed414
    • Jack Stocker's avatar
      Add delay-init quirk for Corsair K70 RGB keyboards · e587f0e7
      Jack Stocker authored
      commit 7a1646d9 upstream.
      
      Following on from this patch: https://lkml.org/lkml/2017/11/3/516,
      Corsair K70 RGB keyboards also require the DELAY_INIT quirk to
      start correctly at boot.
      
      Device ids found here:
      usb 3-3: New USB device found, idVendor=1b1c, idProduct=1b13
      usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
      usb 3-3: Product: Corsair K70 RGB Gaming Keyboard
      Signed-off-by: default avatarJack Stocker <jackstocker.93@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e587f0e7
    • Michael Weiser's avatar
      arm64: Disable unhandled signal log messages by default · 56b57bd2
      Michael Weiser authored
      commit 5ee39a71 upstream.
      
      aarch64 unhandled signal kernel messages are very verbose, suggesting
      them to be more of a debugging aid:
      
      sigsegv[33]: unhandled level 2 translation fault (11) at 0x00000000, esr
      0x92000046, in sigsegv[400000+71000]
      CPU: 1 PID: 33 Comm: sigsegv Tainted: G        W        4.15.0-rc3+ #3
      Hardware name: linux,dummy-virt (DT)
      pstate: 60000000 (nZCv daif -PAN -UAO)
      pc : 0x4003f4
      lr : 0x4006bc
      sp : 0000fffffe94a060
      x29: 0000fffffe94a070 x28: 0000000000000000
      x27: 0000000000000000 x26: 0000000000000000
      x25: 0000000000000000 x24: 00000000004001b0
      x23: 0000000000486ac8 x22: 00000000004001c8
      x21: 0000000000000000 x20: 0000000000400be8
      x19: 0000000000400b30 x18: 0000000000484728
      x17: 000000000865ffc8 x16: 000000000000270f
      x15: 00000000000000b0 x14: 0000000000000002
      x13: 0000000000000001 x12: 0000000000000000
      x11: 0000000000000000 x10: 0008000020008008
      x9 : 000000000000000f x8 : ffffffffffffffff
      x7 : 0004000000000000 x6 : ffffffffffffffff
      x5 : 0000000000000000 x4 : 0000000000000000
      x3 : 00000000004003e4 x2 : 0000fffffe94a1e8
      x1 : 000000000000000a x0 : 0000000000000000
      
      Disable them by default, so they can be enabled using
      /proc/sys/debug/exception-trace.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarMichael Weiser <michael.weiser@gmx.de>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      56b57bd2
    • AMAN DEEP's avatar
      usb: ohci: Proper handling of ed_rm_list to handle race condition between... · 04dcdd0e
      AMAN DEEP authored
      usb: ohci: Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks()
      
      commit 46408ea5 upstream.
      
      There is a race condition between finish_unlinks->finish_urb() function
      and usb_kill_urb() in ohci controller case. The finish_urb calls
      spin_unlock(&ohci->lock) before usb_hcd_giveback_urb() function call,
      then if during this time, usb_kill_urb is called for another endpoint,
      then new ed will be added to ed_rm_list at beginning for unlink, and
      ed_rm_list will point to newly added.
      
      When finish_urb() is completed in finish_unlinks() and ed->td_list
      becomes empty as in below code (in finish_unlinks() function):
      
              if (list_empty(&ed->td_list)) {
                      *last = ed->ed_next;
                      ed->ed_next = NULL;
              } else if (ohci->rh_state == OHCI_RH_RUNNING) {
                      *last = ed->ed_next;
                      ed->ed_next = NULL;
                      ed_schedule(ohci, ed);
              }
      
      The *last = ed->ed_next will make ed_rm_list to point to ed->ed_next
      and previously added ed by usb_kill_urb will be left unreferenced by
      ed_rm_list. This causes usb_kill_urb() hang forever waiting for
      finish_unlink to remove added ed from ed_rm_list.
      
      The main reason for hang in this race condtion is addition and removal
      of ed from ed_rm_list in the beginning during usb_kill_urb and later
      last* is modified in finish_unlinks().
      
      As suggested by Alan Stern, the solution for proper handling of
      ohci->ed_rm_list is to remove ed from the ed_rm_list before finishing
      any URBs. Then at the end, we can add ed back to the list if necessary.
      
      This properly handle the updated ohci->ed_rm_list in usb_kill_urb().
      
      Fixes: 977dcfdc ("USB: OHCI: don't lose track of EDs when a controller dies")
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarAman Deep <aman.deep@samsung.com>
      Signed-off-by: default avatarJeffy Chen <jeffy.chen@rock-chips.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      04dcdd0e
    • Shanker Donthineni's avatar
      irqchip/gic-v3: Use wmb() instead of smb_wmb() in gic_raise_softirq() · 9eda5e8c
      Shanker Donthineni authored
      commit 21ec30c0 upstream.
      
      A DMB instruction can be used to ensure the relative order of only
      memory accesses before and after the barrier. Since writes to system
      registers are not memory operations, barrier DMB is not sufficient
      for observability of memory accesses that occur before ICC_SGI1R_EL1
      writes.
      
      A DSB instruction ensures that no instructions that appear in program
      order after the DSB instruction, can execute until the DSB instruction
      has completed.
      
      Cc: stable@vger.kernel.org
      Acked-by: Will Deacon <will.deacon@arm.com>,
      Signed-off-by: default avatarShanker Donthineni <shankerd@codeaurora.org>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9eda5e8c
    • Arnd Bergmann's avatar
      x86/oprofile: Fix bogus GCC-8 warning in nmi_setup() · e169f13c
      Arnd Bergmann authored
      commit 85c615eb upstream.
      
      GCC-8 shows a warning for the x86 oprofile code that copies per-CPU
      data from CPU 0 to all other CPUs, which when building a non-SMP
      kernel turns into a memcpy() with identical source and destination
      pointers:
      
       arch/x86/oprofile/nmi_int.c: In function 'mux_clone':
       arch/x86/oprofile/nmi_int.c:285:2: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
         memcpy(per_cpu(cpu_msrs, cpu).multiplex,
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                per_cpu(cpu_msrs, 0).multiplex,
                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                sizeof(struct op_msr) * model->num_virt_counters);
                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       arch/x86/oprofile/nmi_int.c: In function 'nmi_setup':
       arch/x86/oprofile/nmi_int.c:466:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
       arch/x86/oprofile/nmi_int.c:470:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
      
      I have analyzed a number of such warnings now: some are valid and the
      GCC warning is welcome. Others turned out to be false-positives, and
      GCC was changed to not warn about those any more. This is a corner case
      that is a false-positive but the GCC developers feel it's better to keep
      warning about it.
      
      In this case, it seems best to work around it by telling GCC
      a little more clearly that this code path is never hit with
      an IS_ENABLED() configuration check.
      
      Cc:stable as we also want old kernels to build cleanly with GCC-8.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: Jessica Yu <jeyu@kernel.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Martin Sebor <msebor@gcc.gnu.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Robert Richter <rric@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: oprofile-list@lists.sf.net
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/20180220205826.2008875-1-arnd@arndb.de
      Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84095Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e169f13c
    • Lars-Peter Clausen's avatar
      iio: adis_lib: Initialize trigger before requesting interrupt · b19f9c43
      Lars-Peter Clausen authored
      commit f027e0b3 upstream.
      
      The adis_probe_trigger() creates a new IIO trigger and requests an
      interrupt associated with the trigger. The interrupt uses the generic
      iio_trigger_generic_data_rdy_poll() function as its interrupt handler.
      
      Currently the driver initializes some fields of the trigger structure after
      the interrupt has been requested. But an interrupt can fire as soon as it
      has been requested. This opens up a race condition.
      
      iio_trigger_generic_data_rdy_poll() will access the trigger data structure
      and dereference the ops field. If the ops field is not yet initialized this
      will result in a NULL pointer deref.
      
      It is not expected that the device generates an interrupt at this point, so
      typically this issue did not surface unless e.g. due to a hardware
      misconfiguration (wrong interrupt number, wrong polarity, etc.).
      
      But some newer devices from the ADIS family start to generate periodic
      interrupts in their power-on reset configuration and unfortunately the
      interrupt can not be masked in the device.  This makes the race condition
      much more visible and the following crash has been observed occasionally
      when booting a system using the ADIS16460.
      
      	Unable to handle kernel NULL pointer dereference at virtual address 00000008
      	pgd = c0004000
      	[00000008] *pgd=00000000
      	Internal error: Oops: 5 [#1] PREEMPT SMP ARM
      	Modules linked in:
      	CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-04126-gf9739f0-dirty #257
      	Hardware name: Xilinx Zynq Platform
      	task: ef04f640 task.stack: ef050000
      	PC is at iio_trigger_notify_done+0x30/0x68
      	LR is at iio_trigger_generic_data_rdy_poll+0x18/0x20
      	pc : [<c042d868>]    lr : [<c042d924>]    psr: 60000193
      	sp : ef051bb8  ip : 00000000  fp : ef106400
      	r10: c081d80a  r9 : ef3bfa00  r8 : 00000087
      	r7 : ef051bec  r6 : 00000000  r5 : ef3bfa00  r4 : ee92ab00
      	r3 : 00000000  r2 : 00000000  r1 : 00000000  r0 : ee97e400
      	Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
      	Control: 18c5387d  Table: 0000404a  DAC: 00000051
      	Process swapper/0 (pid: 1, stack limit = 0xef050210)
      	[<c042d868>] (iio_trigger_notify_done) from [<c0065b10>] (__handle_irq_event_percpu+0x88/0x118)
      	[<c0065b10>] (__handle_irq_event_percpu) from [<c0065bbc>] (handle_irq_event_percpu+0x1c/0x58)
      	[<c0065bbc>] (handle_irq_event_percpu) from [<c0065c30>] (handle_irq_event+0x38/0x5c)
      	[<c0065c30>] (handle_irq_event) from [<c0068e28>] (handle_level_irq+0xa4/0x130)
      	[<c0068e28>] (handle_level_irq) from [<c0064e74>] (generic_handle_irq+0x24/0x34)
      	[<c0064e74>] (generic_handle_irq) from [<c021ab7c>] (zynq_gpio_irqhandler+0xb8/0x13c)
      	[<c021ab7c>] (zynq_gpio_irqhandler) from [<c0064e74>] (generic_handle_irq+0x24/0x34)
      	[<c0064e74>] (generic_handle_irq) from [<c0065370>] (__handle_domain_irq+0x5c/0xb4)
      	[<c0065370>] (__handle_domain_irq) from [<c000940c>] (gic_handle_irq+0x48/0x8c)
      	[<c000940c>] (gic_handle_irq) from [<c0013e8c>] (__irq_svc+0x6c/0xa8)
      
      To fix this make sure that the trigger is fully initialized before
      requesting the interrupt.
      
      Fixes: ccd2b52f ("staging:iio: Add common ADIS library")
      Reported-by: default avatarRobin Getz <Robin.Getz@analog.com>
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b19f9c43
    • Stefan Windfeldt-Prytz's avatar
      iio: buffer: check if a buffer has been set up when poll is called · f4e23b43
      Stefan Windfeldt-Prytz authored
      commit 4cd140bd upstream.
      
      If no iio buffer has been set up and poll is called return 0.
      Without this check there will be a null pointer dereference when
      calling poll on a iio driver without an iio buffer.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarStefan Windfeldt-Prytz <stefan.windfeldt@axis.com>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f4e23b43
    • Arnd Bergmann's avatar
      cfg80211: fix cfg80211_beacon_dup · bef7f1f0
      Arnd Bergmann authored
      commit bee92d06 upstream.
      
      gcc-8 warns about some obviously incorrect code:
      
      net/mac80211/cfg.c: In function 'cfg80211_beacon_dup':
      net/mac80211/cfg.c:2896:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
      
      From the context, I conclude that we want to copy from beacon into
      new_beacon, as we do in the rest of the function.
      
      Cc: stable@vger.kernel.org
      Fixes: 73da7d5b ("mac80211: add channel switch command and beacon callbacks")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bef7f1f0
    • Tyrel Datwyler's avatar
      scsi: ibmvfc: fix misdefined reserved field in ibmvfc_fcp_rsp_info · ff7c5d12
      Tyrel Datwyler authored
      commit c3981365 upstream.
      
      The fcp_rsp_info structure as defined in the FC spec has an initial 3
      bytes reserved field. The ibmvfc driver mistakenly defined this field as
      4 bytes resulting in the rsp_code field being defined in what should be
      the start of the second reserved field and thus always being reported as
      zero by the driver.
      
      Ideally, we should wire ibmvfc up with libfc for the sake of code
      deduplication, and ease of maintaining standardized structures in a
      single place. However, for now simply fixup the definition in ibmvfc for
      backporting to distros on older kernels. Wiring up with libfc will be
      done in a followup patch.
      
      Cc: <stable@vger.kernel.org>
      Reported-by: default avatarHannes Reinecke <hare@suse.de>
      Signed-off-by: default avatarTyrel Datwyler <tyreld@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ff7c5d12
    • Paolo Abeni's avatar
      ip_tunnel: fix preempt warning in ip tunnel creation/updating · d3bef1e8
      Paolo Abeni authored
      commit f27337e1 upstream.
      
      After the commit e09acddf ("ip_tunnel: replace dst_cache with generic
      implementation"), a preemption debug warning is triggered on ip4
      tunnels updating; the dst cache helper needs to be invoked in unpreemptible
      context.
      
      We don't need to load the cache on tunnel update, so this commit fixes
      the warning replacing the load with a dst cache reset, which is
      preempt safe.
      
      Fixes: e09acddf ("ip_tunnel: replace dst_cache with generic implementation")
      Reported-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Cc: Nathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d3bef1e8
    • Paolo Abeni's avatar
      ip_tunnel: replace dst_cache with generic implementation · e6454536
      Paolo Abeni authored
      commit e09acddf upstream.
      
      The current ip_tunnel cache implementation is prone to a race
      that will cause the wrong dst to be cached on cuncurrent dst cache
      miss and ip tunnel update via netlink.
      
      Replacing with the generic implementation fix the issue.
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Suggested-and-acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Cc: Nathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e6454536
    • Johan Hovold's avatar
      PCI: keystone: Fix interrupt-controller-node lookup · 7de85e49
      Johan Hovold authored
      commit eac56aa3 upstream.
      
      Fix child-node lookup during initialisation which was using the wrong
      OF-helper and ended up searching the whole device tree depth-first
      starting at the parent rather than just matching on its children.
      
      To make things worse, the parent pci node could end up being prematurely
      freed as of_find_node_by_name() drops a reference to its first argument.
      Any matching child interrupt-controller node was also leaked.
      
      Fixes: 0c4ffcfe ("PCI: keystone: Add TI Keystone PCIe driver")
      Cc: stable <stable@vger.kernel.org>     # 3.18
      Acked-by: default avatarMurali Karicheri <m-karicheri2@ti.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      [lorenzo.pieralisi@arm.com: updated commit subject]
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      [johan: backport to 4.4]
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7de85e49
    • Michael Ellerman's avatar
      powerpc/64s: Fix RFI flush dependency on HARDLOCKUP_DETECTOR · 920a5413
      Michael Ellerman authored
      The backport of commit aa8a5e00 ("powerpc/64s: Add support for RFI
      flush of L1-D cache"), incorrectly placed the new RFI flush code
      inside an existing #ifdef CONFIG_HARDLOCKUP_DETECTOR block.
      
      This has the obvious effect of requiring HARDLOCKUP_DETECTOR to be
      enabled in order for RFI flush to be enabled, which is a bug.
      
      Fix it by moving the #endif up to where it belongs.
      
      Fixes: c3892946 ("powerpc/64s: Add support for RFI flush of L1-D cache")
      Reported-by: default avatarBernhard Kaindl <bernhard.kaindl@thalesgroup.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      920a5413
    • Paolo Abeni's avatar
      netfilter: drop outermost socket lock in getsockopt() · 482526ec
      Paolo Abeni authored
      commit 01ea306f upstream.
      
      The Syzbot reported a possible deadlock in the netfilter area caused by
      rtnl lock, xt lock and socket lock being acquired with a different order
      on different code paths, leading to the following backtrace:
      Reviewed-by: default avatarXin Long <lucien.xin@gmail.com>
      
      ======================================================
      WARNING: possible circular locking dependency detected
      4.15.0+ #301 Not tainted
      ------------------------------------------------------
      syzkaller233489/4179 is trying to acquire lock:
        (rtnl_mutex){+.+.}, at: [<0000000048e996fd>] rtnl_lock+0x17/0x20
      net/core/rtnetlink.c:74
      
      but task is already holding lock:
        (&xt[i].mutex){+.+.}, at: [<00000000328553a2>]
      xt_find_table_lock+0x3e/0x3e0 net/netfilter/x_tables.c:1041
      
      which lock already depends on the new lock.
      ===
      
      Since commit 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock
      only in the required scope"), we already acquire the socket lock in
      the innermost scope, where needed. In such commit I forgot to remove
      the outer-most socket lock from the getsockopt() path, this commit
      addresses the issues dropping it now.
      
      v1 -> v2: fix bad subj, added relavant 'fixes' tag
      
      Fixes: 22265a5c ("netfilter: xt_TEE: resolve oif using netdevice notifiers")
      Fixes: 202f59af ("netfilter: ipt_CLUSTERIP: do not hold dev")
      Fixes: 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope")
      Reported-by: syzbot+ddde1c7b7ff7442d7f2d@syzkaller.appspotmail.com
      Suggested-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Tested-by: default avatarKrzysztof Piotr Oledzki <ole@ans.pl>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      482526ec
  2. 25 Feb, 2018 24 commits