1. 20 May, 2017 24 commits
    • Ben Hutchings's avatar
      x86, pmem: Fix cache flushing for iovec write < 8 bytes · f25c69bd
      Ben Hutchings authored
      commit 8376efd3 upstream.
      
      Commit 11e63f6d added cache flushing for unaligned writes from an
      iovec, covering the first and last cache line of a >= 8 byte write and
      the first cache line of a < 8 byte write.  But an unaligned write of
      2-7 bytes can still cover two cache lines, so make sure we flush both
      in that case.
      
      Fixes: 11e63f6d ("x86, pmem: fix broken __copy_user_nocache ...")
      Signed-off-by: default avatarBen Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f25c69bd
    • Andy Lutomirski's avatar
      selftests/x86/ldt_gdt_32: Work around a glibc sigaction() bug · 20fd61db
      Andy Lutomirski authored
      commit 65973dd3 upstream.
      
      i386 glibc is buggy and calls the sigaction syscall incorrectly.
      
      This is asymptomatic for normal programs, but it blows up on
      programs that do evil things with segmentation.  The ldt_gdt
      self-test is an example of such an evil program.
      
      This doesn't appear to be a regression -- I think I just got lucky
      with the uninitialized memory that glibc threw at the kernel when I
      wrote the test.
      
      This hackish fix manually issues sigaction(2) syscalls to undo the
      damage.  Without the fix, ldt_gdt_32 segfaults; with the fix, it
      passes for me.
      
      See: https://sourceware.org/bugzilla/show_bug.cgi?id=21269Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Garnier <thgarnie@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/aaab0f9f93c9af25396f01232608c163a760a668.1490218061.git.luto@kernel.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      20fd61db
    • Ashish Kalra's avatar
      x86/boot: Fix BSS corruption/overwrite bug in early x86 kernel startup · 0dc0e26f
      Ashish Kalra authored
      commit d594aa02 upstream.
      
      The minimum size for a new stack (512 bytes) setup for arch/x86/boot components
      when the bootloader does not setup/provide a stack for the early boot components
      is not "enough".
      
      The setup code executing as part of early kernel startup code, uses the stack
      beyond 512 bytes and accidentally overwrites and corrupts part of the BSS
      section. This is exposed mostly in the early video setup code, where
      it was corrupting BSS variables like force_x, force_y, which in-turn affected
      kernel parameters such as screen_info (screen_info.orig_video_cols) and
      later caused an exception/panic in console_init().
      
      Most recent boot loaders setup the stack for early boot components, so this
      stack overwriting into BSS section issue has not been exposed.
      Signed-off-by: default avatarAshish Kalra <ashish@bluestacks.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20170419152015.10011-1-ashishkalra@Ashishs-MacBook-Pro.localSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0dc0e26f
    • Guenter Roeck's avatar
      usb: hub: Do not attempt to autosuspend disconnected devices · 12001f3a
      Guenter Roeck authored
      commit f5cccf49 upstream.
      
      While running a bind/unbind stress test with the dwc3 usb driver on rk3399,
      the following crash was observed.
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000218
      pgd = ffffffc00165f000
      [00000218] *pgd=000000000174f003, *pud=000000000174f003,
      				*pmd=0000000001750003, *pte=00e8000001751713
      Internal error: Oops: 96000005 [#1] PREEMPT SMP
      Modules linked in: uinput uvcvideo videobuf2_vmalloc cmac
      ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat rfcomm
      xt_mark fuse bridge stp llc zram btusb btrtl btbcm btintel bluetooth
      ip6table_filter mwifiex_pcie mwifiex cfg80211 cdc_ether usbnet r8152 mii joydev
      snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device ppp_async
      ppp_generic slhc tun
      CPU: 1 PID: 29814 Comm: kworker/1:1 Not tainted 4.4.52 #507
      Hardware name: Google Kevin (DT)
      Workqueue: pm pm_runtime_work
      task: ffffffc0ac540000 ti: ffffffc0af4d4000 task.ti: ffffffc0af4d4000
      PC is at autosuspend_check+0x74/0x174
      LR is at autosuspend_check+0x70/0x174
      ...
      Call trace:
      [<ffffffc00080dcc0>] autosuspend_check+0x74/0x174
      [<ffffffc000810500>] usb_runtime_idle+0x20/0x40
      [<ffffffc000785ae0>] __rpm_callback+0x48/0x7c
      [<ffffffc000786af0>] rpm_idle+0x1e8/0x498
      [<ffffffc000787cdc>] pm_runtime_work+0x88/0xcc
      [<ffffffc000249bb8>] process_one_work+0x390/0x6b8
      [<ffffffc00024abcc>] worker_thread+0x480/0x610
      [<ffffffc000251a80>] kthread+0x164/0x178
      [<ffffffc0002045d0>] ret_from_fork+0x10/0x40
      
      Source:
      
      (gdb) l *0xffffffc00080dcc0
      0xffffffc00080dcc0 is in autosuspend_check
      (drivers/usb/core/driver.c:1778).
      1773		/* We don't need to check interfaces that are
      1774		 * disabled for runtime PM.  Either they are unbound
      1775		 * or else their drivers don't support autosuspend
      1776		 * and so they are permanently active.
      1777		 */
      1778		if (intf->dev.power.disable_depth)
      1779			continue;
      1780		if (atomic_read(&intf->dev.power.usage_count) > 0)
      1781			return -EBUSY;
      1782		w |= intf->needs_remote_wakeup;
      
      Code analysis shows that intf is set to NULL in usb_disable_device() prior
      to setting actconfig to NULL. At the same time, usb_runtime_idle() does not
      lock the usb device, and neither does any of the functions in the
      traceback. This means that there is no protection against a race condition
      where usb_disable_device() is removing dev->actconfig->interface[] pointers
      while those are being accessed from autosuspend_check().
      
      To solve the problem, synchronize and validate device state between
      autosuspend_check() and usb_disconnect().
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      12001f3a
    • Guenter Roeck's avatar
      usb: hub: Fix error loop seen after hub communication errors · 90d4e2a6
      Guenter Roeck authored
      commit 245b2eec upstream.
      
      While stress testing a usb controller using a bind/unbind looop, the
      following error loop was observed.
      
      usb 7-1.2: new low-speed USB device number 3 using xhci-hcd
      usb 7-1.2: hub failed to enable device, error -108
      usb 7-1-port2: cannot disable (err = -22)
      usb 7-1-port2: couldn't allocate usb_device
      usb 7-1-port2: cannot disable (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: activate --> -22
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: activate --> -22
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: activate --> -22
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: activate --> -22
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: activate --> -22
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: activate --> -22
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: activate --> -22
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: activate --> -22
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      ** 57 printk messages dropped ** hub 7-1:1.0: activate --> -22
      ** 82 printk messages dropped ** hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      
      This continues forever. After adding tracebacks into the code,
      the call sequence leading to this is found to be as follows.
      
      [<ffffffc0007fc8e0>] hub_activate+0x368/0x7b8
      [<ffffffc0007fceb4>] hub_resume+0x2c/0x3c
      [<ffffffc00080b3b8>] usb_resume_interface.isra.6+0x128/0x158
      [<ffffffc00080b5d0>] usb_suspend_both+0x1e8/0x288
      [<ffffffc00080c9c4>] usb_runtime_suspend+0x3c/0x98
      [<ffffffc0007820a0>] __rpm_callback+0x48/0x7c
      [<ffffffc00078217c>] rpm_callback+0xa8/0xd4
      [<ffffffc000786234>] rpm_suspend+0x84/0x758
      [<ffffffc000786ca4>] rpm_idle+0x2c8/0x498
      [<ffffffc000786ed4>] __pm_runtime_idle+0x60/0xac
      [<ffffffc00080eba8>] usb_autopm_put_interface+0x6c/0x7c
      [<ffffffc000803798>] hub_event+0x10ac/0x12ac
      [<ffffffc000249bb8>] process_one_work+0x390/0x6b8
      [<ffffffc00024abcc>] worker_thread+0x480/0x610
      [<ffffffc000251a80>] kthread+0x164/0x178
      [<ffffffc0002045d0>] ret_from_fork+0x10/0x40
      
      kick_hub_wq() is called from hub_activate() even after failures to
      communicate with the hub. This results in an endless sequence of
      hub event -> hub activate -> wq trigger -> hub event -> ...
      
      Provide two solutions for the problem.
      
      - Only trigger the hub event queue if communication with the hub
        is successful.
      - After a suspend failure, only resume already suspended interfaces
        if the communication with the device is still possible.
      
      Each of the changes fixes the observed problem. Use both to improve
      robustness.
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      90d4e2a6
    • Alexey Brodkin's avatar
      usb: Make sure usb/phy/of gets built-in · 8e3b0f66
      Alexey Brodkin authored
      commit 3d615964 upstream.
      
      DWC3 driver uses of_usb_get_phy_mode() which is
      implemented in drivers/usb/phy/of.c and in bare minimal
      configuration it might not be pulled in kernel binary.
      
      In case of ARC or ARM this could be easily reproduced with
      "allnodefconfig" +CONFIG_USB=m +CONFIG_USB_DWC3=m.
      
      On building all ends-up with:
      ---------------------->8------------------
        Kernel: arch/arm/boot/Image is ready
        Kernel: arch/arm/boot/zImage is ready
        Building modules, stage 2.
        MODPOST 5 modules
      ERROR: "of_usb_get_phy_mode" [drivers/usb/dwc3/dwc3.ko] undefined!
      make[1]: *** [__modpost] Error 1
      make: *** [modules] Error 2
      ---------------------->8------------------
      Signed-off-by: default avatarAlexey Brodkin <abrodkin@synopsys.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Geert Uytterhoeven <geert+renesas@glider.be>
      Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Felipe Balbi <balbi@kernel.org>
      Cc: Felix Fietkau <nbd@nbd.name>
      Cc: Jeremy Kerr <jk@ozlabs.org>
      Cc: linux-snps-arc@lists.infradead.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8e3b0f66
    • Romain Izard's avatar
      usb: gadget: legacy gadgets are optional · 6a9fc06a
      Romain Izard authored
      commit 6e253d0f upstream.
      
      With commit bc49d1d1 ("usb: gadget: don't couple configfs to legacy
      gadgets"),it is possible to build a modular kernel with both built-in
      configfs support and modular legacy gadget drivers.
      
      But when building a kernel without modules, it is also necessary to be
      able to build with configfs but without any legacy gadget driver. This
      was a possible configuration when the USB_CONFIGFS was a part of the
      choice options, but not anymore.
      
      Mark the choice for legacy gadget drivers as optional restores this.
      
      Fixes: bc49d1d1 ("usb: gadget: don't couple configfs to legacy gadgets")
      Signed-off-by: default avatarRomain Izard <romain.izard.pro@gmail.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6a9fc06a
    • Gustavo A. R. Silva's avatar
      usb: misc: add missing continue in switch · 84759deb
      Gustavo A. R. Silva authored
      commit 2c930e3d upstream.
      
      Add missing continue in switch.
      
      Addresses-Coverity-ID: 1248733
      Signed-off-by: default avatarGustavo A. R. Silva <garsilva@embeddedor.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      84759deb
    • Ian Abbott's avatar
      staging: comedi: jr3_pci: cope with jiffies wraparound · 69f8945b
      Ian Abbott authored
      commit 8ec04a49 upstream.
      
      The timer expiry routine `jr3_pci_poll_dev()` checks for expiry by
      checking whether the absolute value of `jiffies` (stored in local
      variable `now`) is greater than the expected expiry time in jiffy units.
      This will fail when `jiffies` wraps around.  Also, it seems to make
      sense to handle the expiry one jiffy earlier than the current test.  Use
      `time_after_eq()` to check for expiry.
      Signed-off-by: default avatarIan Abbott <abbotti@mev.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      69f8945b
    • Ian Abbott's avatar
      staging: comedi: jr3_pci: fix possible null pointer dereference · 6e4c973a
      Ian Abbott authored
      commit 45292be0 upstream.
      
      For some reason, the driver does not consider allocation of the
      subdevice private data to be a fatal error when attaching the COMEDI
      device.  It tests the subdevice private data pointer for validity at
      certain points, but omits some crucial tests.  In particular,
      `jr3_pci_auto_attach()` calls `jr3_pci_alloc_spriv()` to allocate and
      initialize the subdevice private data, but the same function
      subsequently dereferences the pointer to access the `next_time_min` and
      `next_time_max` members without checking it first.  The other missing
      test is in the timer expiry routine `jr3_pci_poll_dev()`, but it will
      crash before it gets that far.
      
      Fix the bug by returning `-ENOMEM` from `jr3_pci_auto_attach()` as soon
      as one of the calls to `jr3_pci_alloc_spriv()` returns `NULL`.  The
      COMEDI core will subsequently call `jr3_pci_detach()` to clean up.
      Signed-off-by: default avatarIan Abbott <abbotti@mev.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6e4c973a
    • Sean Young's avatar
      staging: sir: fill in missing fields and fix probe · 99185235
      Sean Young authored
      commit cf9ed9aa upstream.
      
      Some fields are left blank.
      Signed-off-by: default avatarSean Young <sean@mess.org>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      99185235
    • Aditya Shankar's avatar
      staging: wilc1000: Fix problem with wrong vif index · 89cb8fcc
      Aditya Shankar authored
      commit 0e490657 upstream.
      
      The vif->idx value is always 0 for two interfaces.
      
      wl->vif_num = 0;
      
      loop {
           ...
      
           vif->idx = wl->vif_num;
           ...
           wl->vif_num = i;
            ....
           i++;
           ...
      }
      
      At present, vif->idx is assigned the value of wl->vif_num
      at the beginning of this block and device is initialized
      based on this index value.
      In the next iteration, wl->vif_num is still 0 as it is only updated
      later but gets assigned to vif->idx in the beginning. This causes problems
      later when we try to reference a particular interface and also while
      configuring the firmware.
      
      This patch moves the assignment to vif->idx from the beginning
      of the block to after wl->vif_num is updated with latest value of i.
      
      Fixes: commit 735bb39c ("staging: wilc1000: simplify vif[i]->ndev accesses")
      Signed-off-by: default avatarAditya Shankar <aditya.shankar@microchip.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      89cb8fcc
    • Johan Hovold's avatar
      staging: gdm724x: gdm_mux: fix use-after-free on module unload · 22d8767d
      Johan Hovold authored
      commit b58f45c8 upstream.
      
      Make sure to deregister the USB driver before releasing the tty driver
      to avoid use-after-free in the USB disconnect callback where the tty
      devices are deregistered.
      
      Fixes: 61e12104 ("staging: gdm7240: adding LTE USB driver")
      Cc: Won Kang <wkang77@gmail.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      22d8767d
    • Malcolm Priestley's avatar
      staging: vt6656: use off stack for out buffer USB transfers. · af685eef
      Malcolm Priestley authored
      commit 12ecd24e upstream.
      
      Since 4.9 mandated USB buffers be heap allocated this causes the driver
      to fail.
      
      Since there is a wide range of buffer sizes use kmemdup to create
      allocated buffer.
      Signed-off-by: default avatarMalcolm Priestley <tvboxspy@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      af685eef
    • Malcolm Priestley's avatar
      staging: vt6656: use off stack for in buffer USB transfers. · 5ba4fd33
      Malcolm Priestley authored
      commit 05c0cf88 upstream.
      
      Since 4.9 mandated USB buffers to be heap allocated. This causes
      the driver to fail.
      
      Create buffer for USB transfers.
      Signed-off-by: default avatarMalcolm Priestley <tvboxspy@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5ba4fd33
    • Bjørn Mork's avatar
      USB: Revert "cdc-wdm: fix "out-of-sync" due to missing notifications" · f49d36b7
      Bjørn Mork authored
      commit 19445816 upstream.
      
      This reverts commit 833415a3 ("cdc-wdm: fix "out-of-sync" due to
      missing notifications")
      
      There have been several reports of wdm_read returning unexpected EIO
      errors with QMI devices using the qmi_wwan driver. The reporters
      confirm that reverting prevents these errors. I have been unable to
      reproduce the bug myself, and have no explanation to offer either. But
      reverting is the safe choice here, given that the commit was an
      attempt to work around a firmware problem.  Living with a firmware
      problem is still better than adding driver bugs.
      Reported-by: default avatarKasper Holtze <kasper@holtze.dk>
      Reported-by: default avatarAleksander Morgado <aleksander@aleksander.es>
      Reported-by: default avatarDaniele Palmas <dnlplm@gmail.com>
      Fixes: 833415a3 ("cdc-wdm: fix "out-of-sync" due to missing notifications")
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Acked-by: default avatarOliver Neukum <oneukum@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f49d36b7
    • Ajay Kaher's avatar
      USB: Proper handling of Race Condition when two USB class drivers try to call... · 2c33341c
      Ajay Kaher authored
      USB: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously
      
      commit 2f86a96b upstream.
      
      There is race condition when two USB class drivers try to call
      init_usb_class at the same time and leads to crash.
      code path: probe->usb_register_dev->init_usb_class
      
      To solve this, mutex locking has been added in init_usb_class() and
      destroy_usb_class().
      
      As pointed by Alan, removed "if (usb_class)" test from destroy_usb_class()
      because usb_class can never be NULL there.
      Signed-off-by: default avatarAjay Kaher <ajay.kaher@samsung.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      2c33341c
    • Marek Vasut's avatar
      USB: serial: ftdi_sio: add device ID for Microsemi/Arrow SF2PLUS Dev Kit · 2436236e
      Marek Vasut authored
      commit 31c5d192 upstream.
      
      This development kit has an FT4232 on it with a custom USB VID/PID.
      The FT4232 provides four UARTs, but only two are used. The UART 0
      is used by the FlashPro5 programmer and UART 2 is connected to the
      SmartFusion2 CortexM3 SoC UART port.
      
      Note that the USB VID is registered to Actel according to Linux USB
      VID database, but that was acquired by Microsemi.
      Signed-off-by: default avatarMarek Vasut <marex@denx.de>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2436236e
    • Peter Chen's avatar
      usb: host: xhci: print correct command ring address · f34b103c
      Peter Chen authored
      commit 6fc091fb upstream.
      
      Print correct command ring address using 'val_64'.
      Signed-off-by: default avatarPeter Chen <peter.chen@nxp.com>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f34b103c
    • Roger Quadros's avatar
      usb: xhci: bInterval quirk for TI TUSB73x0 · c5379cf6
      Roger Quadros authored
      commit 69307ccb upstream.
      
      As per [1] issue #4,
      "The periodic EP scheduler always tries to schedule the EPs
      that have large intervals (interval equal to or greater than
      128 microframes) into different microframes. So it maintains
      an internal counter and increments for each large interval
      EP added. When the counter is greater than 128, the scheduler
      rejects the new EP. So when the hub re-enumerated 128 times,
      it triggers this condition."
      
      This results in Bandwidth error when devices with periodic
      endpoints (ISO/INT) having bInterval > 7 are plugged and
      unplugged several times on a TUSB73x0 XHCI host.
      
      Workaround this issue by limiting the bInterval to 7
      (i.e. interval to 6) for High-speed or faster periodic endpoints.
      
      [1] - http://www.ti.com/lit/er/sllz076/sllz076.pdfSigned-off-by: default avatarRoger Quadros <rogerq@ti.com>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c5379cf6
    • Nicholas Bellinger's avatar
      iscsi-target: Set session_fall_back_to_erl0 when forcing reinstatement · f9a45058
      Nicholas Bellinger authored
      commit 197b806a upstream.
      
      While testing modification of per se_node_acl queue_depth forcing
      session reinstatement via lio_target_nacl_cmdsn_depth_store() ->
      core_tpg_set_initiator_node_queue_depth(), a hung task bug triggered
      when changing cmdsn_depth invoked session reinstatement while an iscsi
      login was already waiting for session reinstatement to complete.
      
      This can happen when an outstanding se_cmd descriptor is taking a
      long time to complete, and session reinstatement from iscsi login
      or cmdsn_depth change occurs concurrently.
      
      To address this bug, explicitly set session_fall_back_to_erl0 = 1
      when forcing session reinstatement, so session reinstatement is
      not attempted if an active session is already being shutdown.
      
      This patch has been tested with two scenarios.  The first when
      iscsi login is blocked waiting for iscsi session reinstatement
      to complete followed by queue_depth change via configfs, and
      second when queue_depth change via configfs us blocked followed
      by a iscsi login driven session reinstatement.
      
      Note this patch depends on commit d36ad77f to handle multiple
      sessions per se_node_acl when changing cmdsn_depth, and for
      pre v4.5 kernels will need to be included for stable as well.
      Reported-by: default avatarGary Guo <ghg@datera.io>
      Tested-by: default avatarGary Guo <ghg@datera.io>
      Cc: Gary Guo <ghg@datera.io>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f9a45058
    • Bart Van Assche's avatar
      target/fileio: Fix zero-length READ and WRITE handling · 14a89002
      Bart Van Assche authored
      commit 59ac9c07 upstream.
      
      This patch fixes zero-length READ and WRITE handling in target/FILEIO,
      which was broken a long time back by:
      
      Since:
      
        commit d81cb447
        Author: Paolo Bonzini <pbonzini@redhat.com>
        Date:   Mon Sep 17 16:36:11 2012 -0700
      
            target: go through normal processing for all zero-length commands
      
      which moved zero-length READ and WRITE completion out of target-core,
      to doing submission into backend driver code.
      
      To address this, go ahead and invoke target_complete_cmd() for any
      non negative return value in fd_do_rw().
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Cc: Andy Grover <agrover@redhat.com>
      Cc: David Disseldorp <ddiss@suse.de>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      14a89002
    • Nicholas Bellinger's avatar
      target: Fix compare_and_write_callback handling for non GOOD status · 25ed8588
      Nicholas Bellinger authored
      commit a71a5dc7 upstream.
      
      Following the bugfix for handling non SAM_STAT_GOOD COMPARE_AND_WRITE
      status during COMMIT phase in commit 9b2792c3, the same bug exists
      for the READ phase as well.
      
      This would manifest first as a lost SCSI response, and eventual
      hung task during fabric driver logout or re-login, as existing
      shutdown logic waited for the COMPARE_AND_WRITE se_cmd->cmd_kref
      to reach zero.
      
      To address this bug, compare_and_write_callback() has been changed
      to set post_ret = 1 and return TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE
      as necessary to signal failure status.
      Reported-by: default avatarBill Borsari <wgb@datera.io>
      Cc: Bill Borsari <wgb@datera.io>
      Tested-by: default avatarGary Guo <ghg@datera.io>
      Cc: Gary Guo <ghg@datera.io>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      25ed8588
    • Juergen Gross's avatar
      xen: adjust early dom0 p2m handling to xen hypervisor behavior · 1ec6f081
      Juergen Gross authored
      commit 69861e0a upstream.
      
      When booted as pv-guest the p2m list presented by the Xen is already
      mapped to virtual addresses. In dom0 case the hypervisor might make use
      of 2M- or 1G-pages for this mapping. Unfortunately while being properly
      aligned in virtual and machine address space, those pages might not be
      aligned properly in guest physical address space.
      
      So when trying to obtain the guest physical address of such a page
      pud_pfn() and pmd_pfn() must be avoided as those will mask away guest
      physical address bits not being zero in this special case.
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Reviewed-by: default avatarJan Beulich <jbeulich@suse.com>
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1ec6f081
  2. 14 May, 2017 16 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.11.1 · 4c71e91a
      Greg Kroah-Hartman authored
      4c71e91a
    • Ilya Dryomov's avatar
      block: get rid of blk_integrity_revalidate() · 0873ab02
      Ilya Dryomov authored
      commit 19b7ccf8 upstream.
      
      Commit 25520d55 ("block: Inline blk_integrity in struct gendisk")
      introduced blk_integrity_revalidate(), which seems to assume ownership
      of the stable pages flag and unilaterally clears it if no blk_integrity
      profile is registered:
      
          if (bi->profile)
                  disk->queue->backing_dev_info->capabilities |=
                          BDI_CAP_STABLE_WRITES;
          else
                  disk->queue->backing_dev_info->capabilities &=
                          ~BDI_CAP_STABLE_WRITES;
      
      It's called from revalidate_disk() and rescan_partitions(), making it
      impossible to enable stable pages for drivers that support partitions
      and don't use blk_integrity: while the call in revalidate_disk() can be
      trivially worked around (see zram, which doesn't support partitions and
      hence gets away with zram_revalidate_disk()), rescan_partitions() can
      be triggered from userspace at any time.  This breaks rbd, where the
      ceph messenger is responsible for generating/verifying CRCs.
      
      Since blk_integrity_{un,}register() "must" be used for (un)registering
      the integrity profile with the block layer, move BDI_CAP_STABLE_WRITES
      setting there.  This way drivers that call blk_integrity_register() and
      use integrity infrastructure won't interfere with drivers that don't
      but still want stable pages.
      
      Fixes: 25520d55 ("block: Inline blk_integrity in struct gendisk")
      Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Mike Snitzer <snitzer@redhat.com>
      Tested-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0873ab02
    • Boris Ostrovsky's avatar
      xen: Revert commits da72ff5b and 72a9b186 · 3ed024e2
      Boris Ostrovsky authored
      commit 84d582d2 upstream.
      
      Recent discussion (http://marc.info/?l=xen-devel&m=149192184523741)
      established that commit 72a9b186 ("xen: Remove event channel
      notification through Xen PCI platform device") (and thus commit
      da72ff5b ("partially revert "xen: Remove event channel
      notification through Xen PCI platform device"")) are unnecessary and,
      in fact, prevent HVM guests from booting on Xen releases prior to 4.0
      
      Therefore we revert both of those commits.
      
      The summary of that discussion is below:
      
        Here is the brief summary of the current situation:
      
        Before the offending commit (72a9b186):
      
        1) INTx does not work because of the reset_watches path.
        2) The reset_watches path is only taken if you have Xen > 4.0
        3) The Linux Kernel by default will use vector inject if the hypervisor
           support. So even INTx does not work no body running the kernel with
           Xen > 4.0 would notice. Unless he explicitly disabled this feature
           either in the kernel or in Xen (and this can only be disabled by
           modifying the code, not user-supported way to do it).
      
        After the offending commit (+ partial revert):
      
        1) INTx is no longer support for HVM (only for PV guests).
        2) Any HVM guest The kernel will not boot on Xen < 4.0 which does
           not have vector injection support. Since the only other mode
           supported is INTx which.
      
        So based on this summary, I think before commit (72a9b186) we were
        in much better position from a user point of view.
      Signed-off-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Reviewed-by: default avatarJuergen Gross <jgross@suse.com>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: x86@kernel.org
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Stefano Stabellini <sstabellini@kernel.org>
      Cc: Julien Grall <julien.grall@arm.com>
      Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Ross Lagerwall <ross.lagerwall@citrix.com>
      Cc: xen-devel@lists.xenproject.org
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-pci@vger.kernel.org
      Cc: Anthony Liguori <aliguori@amazon.com>
      Cc: KarimAllah Ahmed <karahmed@amazon.de>
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3ed024e2
    • Stefano Stabellini's avatar
      xen/arm,arm64: fix xen_dma_ops after 815dd187 "Consolidate get_dma_ops..." · 5e25479e
      Stefano Stabellini authored
      commit e0586326 upstream.
      
      The following commit:
      
        commit 815dd187
        Author: Bart Van Assche <bart.vanassche@sandisk.com>
        Date:   Fri Jan 20 13:04:04 2017 -0800
      
            treewide: Consolidate get_dma_ops() implementations
      
      rearranges get_dma_ops in a way that xen_dma_ops are not returned when
      running on Xen anymore, dev->dma_ops is returned instead (see
      arch/arm/include/asm/dma-mapping.h:get_arch_dma_ops and
      include/linux/dma-mapping.h:get_dma_ops).
      
      Fix the problem by storing dev->dma_ops in dev_archdata, and setting
      dev->dma_ops to xen_dma_ops. This way, xen_dma_ops is returned naturally
      by get_dma_ops. The Xen code can retrieve the original dev->dma_ops from
      dev_archdata when needed. It also allows us to remove __generic_dma_ops
      from common headers.
      Signed-off-by: default avatarStefano Stabellini <sstabellini@kernel.org>
      Tested-by: default avatarJulien Grall <julien.grall@arm.com>
      Suggested-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      CC: linux@armlinux.org.uk
      CC: catalin.marinas@arm.com
      CC: will.deacon@arm.com
      CC: boris.ostrovsky@oracle.com
      CC: jgross@suse.com
      CC: Julien Grall <julien.grall@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5e25479e
    • Jin Qian's avatar
      f2fs: sanity check segment count · c7f765b5
      Jin Qian authored
      commit b9dd4618 upstream.
      
      F2FS uses 4 bytes to represent block address. As a result, supported
      size of disk is 16 TB and it equals to 16 * 1024 * 1024 / 2 segments.
      Signed-off-by: default avatarJin Qian <jinqian@google.com>
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c7f765b5
    • Jon Mason's avatar
      net: mdio-mux: bcm-iproc: call mdiobus_free() in error path · 275e2edb
      Jon Mason authored
      [ Upstream commit 922c60e8 ]
      
      If an error is encountered in mdio_mux_init(), the error path will call
      mdiobus_free().  Since mdiobus_register() has been called prior to
      mdio_mux_init(), the bus->state will not be MDIOBUS_UNREGISTERED.  This
      causes a BUG_ON() in mdiobus_free().  To correct this issue, add an
      error path for mdio_mux_init() which calls mdiobus_unregister() prior to
      mdiobus_free().
      Signed-off-by: default avatarJon Mason <jon.mason@broadcom.com>
      Fixes: 98bc865a ("net: mdio-mux: Add MDIO mux driver for iProc SoCs")
      Acked-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      275e2edb
    • Daniel Borkmann's avatar
      bpf: don't let ldimm64 leak map addresses on unprivileged · ced12308
      Daniel Borkmann authored
      [ Upstream commit 0d0e5769 ]
      
      The patch fixes two things at once:
      
      1) It checks the env->allow_ptr_leaks and only prints the map address to
         the log if we have the privileges to do so, otherwise it just dumps 0
         as we would when kptr_restrict is enabled on %pK. Given the latter is
         off by default and not every distro sets it, I don't want to rely on
         this, hence the 0 by default for unprivileged.
      
      2) Printing of ldimm64 in the verifier log is currently broken in that
         we don't print the full immediate, but only the 32 bit part of the
         first insn part for ldimm64. Thus, fix this up as well; it's okay to
         access, since we verified all ldimm64 earlier already (including just
         constants) through replace_map_fd_with_map_ptr().
      
      Fixes: 1be7f75d ("bpf: enable non-root eBPF programs")
      Fixes: cbd35700 ("bpf: verifier (add ability to receive verification log)")
      Reported-by: default avatarJann Horn <jannh@google.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ced12308
    • Dan Carpenter's avatar
      bnxt_en: allocate enough space for ->ntp_fltr_bmap · 7a0a483e
      Dan Carpenter authored
      [ Upstream commit ac45bd93 ]
      
      We have the number of longs, but we need to calculate the number of
      bytes required.
      
      Fixes: c0c050c5 ("bnxt_en: New Broadcom ethernet driver.")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Acked-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7a0a483e
    • Eric Dumazet's avatar
      tcp: randomize timestamps on syncookies · f8e3892f
      Eric Dumazet authored
      [ Upstream commit 84b114b9 ]
      
      Whole point of randomization was to hide server uptime, but an attacker
      can simply start a syn flood and TCP generates 'old style' timestamps,
      directly revealing server jiffies value.
      
      Also, TSval sent by the server to a particular remote address vary
      depending on syncookies being sent or not, potentially triggering PAWS
      drops for innocent clients.
      
      Lets implement proper randomization, including for SYNcookies.
      
      Also we do not need to export sysctl_tcp_timestamps, since it is not
      used from a module.
      
      In v2, I added Florian feedback and contribution, adding tsoff to
      tcp_get_cookie_sock().
      
      v3 removed one unused variable in tcp_v4_connect() as Florian spotted.
      
      Fixes: 95a22cae ("tcp: randomize tcp timestamp offsets for each connection")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reviewed-by: default avatarFlorian Westphal <fw@strlen.de>
      Tested-by: default avatarFlorian Westphal <fw@strlen.de>
      Cc: Yuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f8e3892f
    • WANG Cong's avatar
      ipv6: reorder ip6_route_dev_notifier after ipv6_dev_notf · 3960afa2
      WANG Cong authored
      [ Upstream commit 242d3a49 ]
      
      For each netns (except init_net), we initialize its null entry
      in 3 places:
      
      1) The template itself, as we use kmemdup()
      2) Code around dst_init_metrics() in ip6_route_net_init()
      3) ip6_route_dev_notify(), which is supposed to initialize it after
         loopback registers
      
      Unfortunately the last one still happens in a wrong order because
      we expect to initialize net->ipv6.ip6_null_entry->rt6i_idev to
      net->loopback_dev's idev, thus we have to do that after we add
      idev to loopback. However, this notifier has priority == 0 same as
      ipv6_dev_notf, and ipv6_dev_notf is registered after
      ip6_route_dev_notifier so it is called actually after
      ip6_route_dev_notifier. This is similar to commit 2f460933
      ("ipv6: initialize route null entry in addrconf_init()") which
      fixes init_net.
      
      Fix it by picking a smaller priority for ip6_route_dev_notifier.
      Also, we have to release the refcnt accordingly when unregistering
      loopback_dev because device exit functions are called before subsys
      exit functions.
      Acked-by: default avatarDavid Ahern <dsahern@gmail.com>
      Tested-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3960afa2
    • WANG Cong's avatar
      ipv6: initialize route null entry in addrconf_init() · 5ee83127
      WANG Cong authored
      [ Upstream commit 2f460933 ]
      
      Andrey reported a crash on init_net.ipv6.ip6_null_entry->rt6i_idev
      since it is always NULL.
      
      This is clearly wrong, we have code to initialize it to loopback_dev,
      unfortunately the order is still not correct.
      
      loopback_dev is registered very early during boot, we lose a chance
      to re-initialize it in notifier. addrconf_init() is called after
      ip6_route_init(), which means we have no chance to correct it.
      
      Fix it by moving this initialization explicitly after
      ipv6_add_dev(init_net.loopback_dev) in addrconf_init().
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Tested-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5ee83127
    • Michal Schmidt's avatar
      rtnetlink: NUL-terminate IFLA_PHYS_PORT_NAME string · 0913e573
      Michal Schmidt authored
      [ Upstream commit 77ef033b ]
      
      IFLA_PHYS_PORT_NAME is a string attribute, so terminate it with \0.
      Otherwise libnl3 fails to validate netlink messages with this attribute.
      "ip -detail a" assumes too that the attribute is NUL-terminated when
      printing it. It often was, due to padding.
      
      I noticed this as libvirtd failing to start on a system with sfc driver
      after upgrading it to Linux 4.11, i.e. when sfc added support for
      phys_port_name.
      Signed-off-by: default avatarMichal Schmidt <mschmidt@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0913e573
    • Alexander Potapenko's avatar
      ipv4, ipv6: ensure raw socket message is big enough to hold an IP header · 165a007e
      Alexander Potapenko authored
      [ Upstream commit 86f4c90a ]
      
      raw_send_hdrinc() and rawv6_send_hdrinc() expect that the buffer copied
      from the userspace contains the IPv4/IPv6 header, so if too few bytes are
      copied, parts of the header may remain uninitialized.
      
      This bug has been detected with KMSAN.
      
      For the record, the KMSAN report:
      
      ==================================================================
      BUG: KMSAN: use of unitialized memory in nf_ct_frag6_gather+0xf5a/0x44a0
      inter: 0
      CPU: 0 PID: 1036 Comm: probe Not tainted 4.11.0-rc5+ #2455
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:16
       dump_stack+0x143/0x1b0 lib/dump_stack.c:52
       kmsan_report+0x16b/0x1e0 mm/kmsan/kmsan.c:1078
       __kmsan_warning_32+0x5c/0xa0 mm/kmsan/kmsan_instr.c:510
       nf_ct_frag6_gather+0xf5a/0x44a0 net/ipv6/netfilter/nf_conntrack_reasm.c:577
       ipv6_defrag+0x1d9/0x280 net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:68
       nf_hook_entry_hookfn ./include/linux/netfilter.h:102
       nf_hook_slow+0x13f/0x3c0 net/netfilter/core.c:310
       nf_hook ./include/linux/netfilter.h:212
       NF_HOOK ./include/linux/netfilter.h:255
       rawv6_send_hdrinc net/ipv6/raw.c:673
       rawv6_sendmsg+0x2fcb/0x41a0 net/ipv6/raw.c:919
       inet_sendmsg+0x3f8/0x6d0 net/ipv4/af_inet.c:762
       sock_sendmsg_nosec net/socket.c:633
       sock_sendmsg net/socket.c:643
       SYSC_sendto+0x6a5/0x7c0 net/socket.c:1696
       SyS_sendto+0xbc/0xe0 net/socket.c:1664
       do_syscall_64+0x72/0xa0 arch/x86/entry/common.c:285
       entry_SYSCALL64_slow_path+0x25/0x25 arch/x86/entry/entry_64.S:246
      RIP: 0033:0x436e03
      RSP: 002b:00007ffce48baf38 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
      RAX: ffffffffffffffda RBX: 00000000004002b0 RCX: 0000000000436e03
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003
      RBP: 00007ffce48baf90 R08: 00007ffce48baf50 R09: 000000000000001c
      R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
      R13: 0000000000401790 R14: 0000000000401820 R15: 0000000000000000
      origin: 00000000d9400053
       save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
       kmsan_save_stack_with_flags mm/kmsan/kmsan.c:362
       kmsan_internal_poison_shadow+0xb1/0x1a0 mm/kmsan/kmsan.c:257
       kmsan_poison_shadow+0x6d/0xc0 mm/kmsan/kmsan.c:270
       slab_alloc_node mm/slub.c:2735
       __kmalloc_node_track_caller+0x1f4/0x390 mm/slub.c:4341
       __kmalloc_reserve net/core/skbuff.c:138
       __alloc_skb+0x2cd/0x740 net/core/skbuff.c:231
       alloc_skb ./include/linux/skbuff.h:933
       alloc_skb_with_frags+0x209/0xbc0 net/core/skbuff.c:4678
       sock_alloc_send_pskb+0x9ff/0xe00 net/core/sock.c:1903
       sock_alloc_send_skb+0xe4/0x100 net/core/sock.c:1920
       rawv6_send_hdrinc net/ipv6/raw.c:638
       rawv6_sendmsg+0x2918/0x41a0 net/ipv6/raw.c:919
       inet_sendmsg+0x3f8/0x6d0 net/ipv4/af_inet.c:762
       sock_sendmsg_nosec net/socket.c:633
       sock_sendmsg net/socket.c:643
       SYSC_sendto+0x6a5/0x7c0 net/socket.c:1696
       SyS_sendto+0xbc/0xe0 net/socket.c:1664
       do_syscall_64+0x72/0xa0 arch/x86/entry/common.c:285
       return_from_SYSCALL_64+0x0/0x6a arch/x86/entry/entry_64.S:246
      ==================================================================
      
      , triggered by the following syscalls:
        socket(PF_INET6, SOCK_RAW, IPPROTO_RAW) = 3
        sendto(3, NULL, 0, 0, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6, "ff00::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EPERM
      
      A similar report is triggered in net/ipv4/raw.c if we use a PF_INET socket
      instead of a PF_INET6 one.
      Signed-off-by: default avatarAlexander Potapenko <glider@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      165a007e
    • Eric Dumazet's avatar
      tcp: do not inherit fastopen_req from parent · 86a9a088
      Eric Dumazet authored
      [ Upstream commit 8b485ce6 ]
      
      Under fuzzer stress, it is possible that a child gets a non NULL
      fastopen_req pointer from its parent at accept() time, when/if parent
      morphs from listener to active session.
      
      We need to make sure this can not happen, by clearing the field after
      socket cloning.
      
      BUG: Double free or freeing an invalid pointer
      Unexpected shadow byte: 0xFB
      CPU: 3 PID: 20933 Comm: syz-executor3 Not tainted 4.11.0+ #306
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs
      01/01/2011
      Call Trace:
       <IRQ>
       __dump_stack lib/dump_stack.c:16 [inline]
       dump_stack+0x292/0x395 lib/dump_stack.c:52
       kasan_object_err+0x1c/0x70 mm/kasan/report.c:164
       kasan_report_double_free+0x5c/0x70 mm/kasan/report.c:185
       kasan_slab_free+0x9d/0xc0 mm/kasan/kasan.c:580
       slab_free_hook mm/slub.c:1357 [inline]
       slab_free_freelist_hook mm/slub.c:1379 [inline]
       slab_free mm/slub.c:2961 [inline]
       kfree+0xe8/0x2b0 mm/slub.c:3882
       tcp_free_fastopen_req net/ipv4/tcp.c:1077 [inline]
       tcp_disconnect+0xc15/0x13e0 net/ipv4/tcp.c:2328
       inet_child_forget+0xb8/0x600 net/ipv4/inet_connection_sock.c:898
       inet_csk_reqsk_queue_add+0x1e7/0x250
      net/ipv4/inet_connection_sock.c:928
       tcp_get_cookie_sock+0x21a/0x510 net/ipv4/syncookies.c:217
       cookie_v4_check+0x1a19/0x28b0 net/ipv4/syncookies.c:384
       tcp_v4_cookie_check net/ipv4/tcp_ipv4.c:1384 [inline]
       tcp_v4_do_rcv+0x731/0x940 net/ipv4/tcp_ipv4.c:1421
       tcp_v4_rcv+0x2dc0/0x31c0 net/ipv4/tcp_ipv4.c:1715
       ip_local_deliver_finish+0x4cc/0xc20 net/ipv4/ip_input.c:216
       NF_HOOK include/linux/netfilter.h:257 [inline]
       ip_local_deliver+0x1ce/0x700 net/ipv4/ip_input.c:257
       dst_input include/net/dst.h:492 [inline]
       ip_rcv_finish+0xb1d/0x20b0 net/ipv4/ip_input.c:396
       NF_HOOK include/linux/netfilter.h:257 [inline]
       ip_rcv+0xd8c/0x19c0 net/ipv4/ip_input.c:487
       __netif_receive_skb_core+0x1ad1/0x3400 net/core/dev.c:4210
       __netif_receive_skb+0x2a/0x1a0 net/core/dev.c:4248
       process_backlog+0xe5/0x6c0 net/core/dev.c:4868
       napi_poll net/core/dev.c:5270 [inline]
       net_rx_action+0xe70/0x18e0 net/core/dev.c:5335
       __do_softirq+0x2fb/0xb99 kernel/softirq.c:284
       do_softirq_own_stack+0x1c/0x30 arch/x86/entry/entry_64.S:899
       </IRQ>
       do_softirq.part.17+0x1e8/0x230 kernel/softirq.c:328
       do_softirq kernel/softirq.c:176 [inline]
       __local_bh_enable_ip+0x1cf/0x1e0 kernel/softirq.c:181
       local_bh_enable include/linux/bottom_half.h:31 [inline]
       rcu_read_unlock_bh include/linux/rcupdate.h:931 [inline]
       ip_finish_output2+0x9ab/0x15e0 net/ipv4/ip_output.c:230
       ip_finish_output+0xa35/0xdf0 net/ipv4/ip_output.c:316
       NF_HOOK_COND include/linux/netfilter.h:246 [inline]
       ip_output+0x1f6/0x7b0 net/ipv4/ip_output.c:404
       dst_output include/net/dst.h:486 [inline]
       ip_local_out+0x95/0x160 net/ipv4/ip_output.c:124
       ip_queue_xmit+0x9a8/0x1a10 net/ipv4/ip_output.c:503
       tcp_transmit_skb+0x1ade/0x3470 net/ipv4/tcp_output.c:1057
       tcp_write_xmit+0x79e/0x55b0 net/ipv4/tcp_output.c:2265
       __tcp_push_pending_frames+0xfa/0x3a0 net/ipv4/tcp_output.c:2450
       tcp_push+0x4ee/0x780 net/ipv4/tcp.c:683
       tcp_sendmsg+0x128d/0x39b0 net/ipv4/tcp.c:1342
       inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:762
       sock_sendmsg_nosec net/socket.c:633 [inline]
       sock_sendmsg+0xca/0x110 net/socket.c:643
       SYSC_sendto+0x660/0x810 net/socket.c:1696
       SyS_sendto+0x40/0x50 net/socket.c:1664
       entry_SYSCALL_64_fastpath+0x1f/0xbe
      RIP: 0033:0x446059
      RSP: 002b:00007faa6761fb58 EFLAGS: 00000282 ORIG_RAX: 000000000000002c
      RAX: ffffffffffffffda RBX: 0000000000000017 RCX: 0000000000446059
      RDX: 0000000000000001 RSI: 0000000020ba3fcd RDI: 0000000000000017
      RBP: 00000000006e40a0 R08: 0000000020ba4ff0 R09: 0000000000000010
      R10: 0000000020000000 R11: 0000000000000282 R12: 0000000000708150
      R13: 0000000000000000 R14: 00007faa676209c0 R15: 00007faa67620700
      Object at ffff88003b5bbcb8, in cache kmalloc-64 size: 64
      Allocated:
      PID = 20909
       save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
       save_stack+0x43/0xd0 mm/kasan/kasan.c:513
       set_track mm/kasan/kasan.c:525 [inline]
       kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:616
       kmem_cache_alloc_trace+0x82/0x270 mm/slub.c:2745
       kmalloc include/linux/slab.h:490 [inline]
       kzalloc include/linux/slab.h:663 [inline]
       tcp_sendmsg_fastopen net/ipv4/tcp.c:1094 [inline]
       tcp_sendmsg+0x221a/0x39b0 net/ipv4/tcp.c:1139
       inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:762
       sock_sendmsg_nosec net/socket.c:633 [inline]
       sock_sendmsg+0xca/0x110 net/socket.c:643
       SYSC_sendto+0x660/0x810 net/socket.c:1696
       SyS_sendto+0x40/0x50 net/socket.c:1664
       entry_SYSCALL_64_fastpath+0x1f/0xbe
      Freed:
      PID = 20909
       save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
       save_stack+0x43/0xd0 mm/kasan/kasan.c:513
       set_track mm/kasan/kasan.c:525 [inline]
       kasan_slab_free+0x73/0xc0 mm/kasan/kasan.c:589
       slab_free_hook mm/slub.c:1357 [inline]
       slab_free_freelist_hook mm/slub.c:1379 [inline]
       slab_free mm/slub.c:2961 [inline]
       kfree+0xe8/0x2b0 mm/slub.c:3882
       tcp_free_fastopen_req net/ipv4/tcp.c:1077 [inline]
       tcp_disconnect+0xc15/0x13e0 net/ipv4/tcp.c:2328
       __inet_stream_connect+0x20c/0xf90 net/ipv4/af_inet.c:593
       tcp_sendmsg_fastopen net/ipv4/tcp.c:1111 [inline]
       tcp_sendmsg+0x23a8/0x39b0 net/ipv4/tcp.c:1139
       inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:762
       sock_sendmsg_nosec net/socket.c:633 [inline]
       sock_sendmsg+0xca/0x110 net/socket.c:643
       SYSC_sendto+0x660/0x810 net/socket.c:1696
       SyS_sendto+0x40/0x50 net/socket.c:1664
       entry_SYSCALL_64_fastpath+0x1f/0xbe
      
      Fixes: e994b2f0 ("tcp: do not lock listener to process SYN packets")
      Fixes: 7db92362 ("tcp: fix potential double free issue for fastopen_req")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Acked-by: default avatarWei Wang <weiwan@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      86a9a088
    • Daniele Palmas's avatar
      net: usb: qmi_wwan: add Telit ME910 support · 0b1d889c
      Daniele Palmas authored
      [ Upstream commit 4c54dc02 ]
      
      This patch adds support for Telit ME910 PID 0x1100.
      Signed-off-by: default avatarDaniele Palmas <dnlplm@gmail.com>
      Acked-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0b1d889c
    • David Ahern's avatar
      net: ipv6: Do not duplicate DAD on link up · 23e761f3
      David Ahern authored
      [ Upstream commit 6d717134 ]
      
      Andrey reported a warning triggered by the rcu code:
      
      ------------[ cut here ]------------
      WARNING: CPU: 1 PID: 5911 at lib/debugobjects.c:289
      debug_print_object+0x175/0x210
      ODEBUG: activate active (active state 1) object type: rcu_head hint:
              (null)
      Modules linked in:
      CPU: 1 PID: 5911 Comm: a.out Not tainted 4.11.0-rc8+ #271
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:16
       dump_stack+0x192/0x22d lib/dump_stack.c:52
       __warn+0x19f/0x1e0 kernel/panic.c:549
       warn_slowpath_fmt+0xe0/0x120 kernel/panic.c:564
       debug_print_object+0x175/0x210 lib/debugobjects.c:286
       debug_object_activate+0x574/0x7e0 lib/debugobjects.c:442
       debug_rcu_head_queue kernel/rcu/rcu.h:75
       __call_rcu.constprop.76+0xff/0x9c0 kernel/rcu/tree.c:3229
       call_rcu_sched+0x12/0x20 kernel/rcu/tree.c:3288
       rt6_rcu_free net/ipv6/ip6_fib.c:158
       rt6_release+0x1ea/0x290 net/ipv6/ip6_fib.c:188
       fib6_del_route net/ipv6/ip6_fib.c:1461
       fib6_del+0xa42/0xdc0 net/ipv6/ip6_fib.c:1500
       __ip6_del_rt+0x100/0x160 net/ipv6/route.c:2174
       ip6_del_rt+0x140/0x1b0 net/ipv6/route.c:2187
       __ipv6_ifa_notify+0x269/0x780 net/ipv6/addrconf.c:5520
       addrconf_ifdown+0xe60/0x1a20 net/ipv6/addrconf.c:3672
      ...
      
      Andrey's reproducer program runs in a very tight loop, calling
      'unshare -n' and then spawning 2 sets of 14 threads running random ioctl
      calls. The relevant networking sequence:
      
      1. New network namespace created via unshare -n
      - ip6tnl0 device is created in down state
      
      2. address added to ip6tnl0
      - equivalent to ip -6 addr add dev ip6tnl0 fd00::bb/1
      - DAD is started on the address and when it completes the host
        route is inserted into the FIB
      
      3. ip6tnl0 is brought up
      - the new fixup_permanent_addr function restarts DAD on the address
      
      4. exit namespace
      - teardown / cleanup sequence starts
      - once in a blue moon, lo teardown appears to happen BEFORE teardown
        of ip6tunl0
        + down on 'lo' removes the host route from the FIB since the dst->dev
          for the route is loobback
        + host route added to rcu callback list
          * rcu callback has not run yet, so rt is NOT on the gc list so it has
            NOT been marked obsolete
      
      5. in parallel to 4. worker_thread runs addrconf_dad_completed
      - DAD on the address on ip6tnl0 completes
      - calls ipv6_ifa_notify which inserts the host route
      
      All of that happens very quickly. The result is that a host route that
      has been deleted from the IPv6 FIB and added to the RCU list is re-inserted
      into the FIB.
      
      The exit namespace eventually gets to cleaning up ip6tnl0 which removes the
      host route from the FIB again, calls the rcu function for cleanup -- and
      triggers the double rcu trace.
      
      The root cause is duplicate DAD on the address -- steps 2 and 3. Arguably,
      DAD should not be started in step 2. The interface is in the down state,
      so it can not really send out requests for the address which makes starting
      DAD pointless.
      
      Since the second DAD was introduced by a recent change, seems appropriate
      to use it for the Fixes tag and have the fixup function only start DAD for
      addresses in the PREDAD state which occurs in addrconf_ifdown if the
      address is retained.
      
      Big thanks to Andrey for isolating a reliable reproducer for this problem.
      Fixes: f1705ec1 ("net: ipv6: Make address flushing on ifdown optional")
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarDavid Ahern <dsahern@gmail.com>
      Tested-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      23e761f3