An error occurred fetching the project authors.
  1. 29 Dec, 2018 30 commits
    • Ihab Zhaika's avatar
      iwlwifi: add new cards for 9560, 9462, 9461 and killer series · 20e98526
      Ihab Zhaika authored
      commit f108703c upstream.
      
      add few PCI ID'S for 9560, 9462, 9461 and killer series.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarIhab Zhaika <ihab.zhaika@intel.com>
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      20e98526
    • Emmanuel Grumbach's avatar
      iwlwifi: mvm: don't send GEO_TX_POWER_LIMIT to old firmwares · adb7ea12
      Emmanuel Grumbach authored
      commit eca1e56c upstream.
      
      Old firmware versions don't support this command. Sending it
      to any firmware before -41.ucode will crash the firmware.
      
      This fixes https://bugzilla.kernel.org/show_bug.cgi?id=201975
      
      Fixes: 66e83903 ("iwlwifi: fix wrong WGDS_WIFI_DATA_SIZE")
      CC: <stable@vger.kernel.org> #4.19+
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      adb7ea12
    • Sergey Senozhatsky's avatar
      panic: avoid deadlocks in re-entrant console drivers · e1240a10
      Sergey Senozhatsky authored
      commit c7c3f05e upstream.
      
      From printk()/serial console point of view panic() is special, because
      it may force CPU to re-enter printk() or/and serial console driver.
      Therefore, some of serial consoles drivers are re-entrant. E.g. 8250:
      
      serial8250_console_write()
      {
      	if (port->sysrq)
      		locked = 0;
      	else if (oops_in_progress)
      		locked = spin_trylock_irqsave(&port->lock, flags);
      	else
      		spin_lock_irqsave(&port->lock, flags);
      	...
      }
      
      panic() does set oops_in_progress via bust_spinlocks(1), so in theory
      we should be able to re-enter serial console driver from panic():
      
      	CPU0
      	<NMI>
      	uart_console_write()
      	serial8250_console_write()		// if (oops_in_progress)
      						//    spin_trylock_irqsave()
      	call_console_drivers()
      	console_unlock()
      	console_flush_on_panic()
      	bust_spinlocks(1)			// oops_in_progress++
      	panic()
      	<NMI/>
      	spin_lock_irqsave(&port->lock, flags)   // spin_lock_irqsave()
      	serial8250_console_write()
      	call_console_drivers()
      	console_unlock()
      	printk()
      	...
      
      However, this does not happen and we deadlock in serial console on
      port->lock spinlock. And the problem is that console_flush_on_panic()
      called after bust_spinlocks(0):
      
      void panic(const char *fmt, ...)
      {
      	bust_spinlocks(1);
      	...
      	bust_spinlocks(0);
      	console_flush_on_panic();
      	...
      }
      
      bust_spinlocks(0) decrements oops_in_progress, so oops_in_progress
      can go back to zero. Thus even re-entrant console drivers will simply
      spin on port->lock spinlock. Given that port->lock may already be
      locked either by a stopped CPU, or by the very same CPU we execute
      panic() on (for instance, NMI panic() on printing CPU) the system
      deadlocks and does not reboot.
      
      Fix this by removing bust_spinlocks(0), so oops_in_progress is always
      set in panic() now and, thus, re-entrant console drivers will trylock
      the port->lock instead of spinning on it forever, when we call them
      from console_flush_on_panic().
      
      Link: http://lkml.kernel.org/r/20181025101036.6823-1-sergey.senozhatsky@gmail.com
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Daniel Wang <wonderfly@google.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
      Cc: Jiri Slaby <jslaby@suse.com>
      Cc: Peter Feiner <pfeiner@google.com>
      Cc: linux-serial@vger.kernel.org
      Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e1240a10
    • Colin Ian King's avatar
      x86/mtrr: Don't copy uninitialized gentry fields back to userspace · 0761921f
      Colin Ian King authored
      commit 32043fa0 upstream.
      
      Currently the copy_to_user of data in the gentry struct is copying
      uninitiaized data in field _pad from the stack to userspace.
      
      Fix this by explicitly memset'ing gentry to zero, this also will zero any
      compiler added padding fields that may be in struct (currently there are
      none).
      
      Detected by CoverityScan, CID#200783 ("Uninitialized scalar variable")
      
      Fixes: b263b31e ("x86, mtrr: Use explicit sizing and padding for the 64-bit ioctls")
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Cc: security@kernel.org
      Link: https://lkml.kernel.org/r/20181218172956.1440-1-colin.king@canonical.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0761921f
    • Dexuan Cui's avatar
      Drivers: hv: vmbus: Return -EINVAL for the sys files for unopened channels · ff53cc35
      Dexuan Cui authored
      commit fc96df16 upstream.
      
      Before 98f4c651, we returned zeros for unopened channels.
      With 98f4c651, we started to return random on-stack values.
      
      We'd better return -EINVAL instead.
      
      Fixes: 98f4c651 ("hv: move ringbuffer bus attributes to dev_groups")
      Cc: stable@vger.kernel.org
      Cc: K. Y. Srinivasan <kys@microsoft.com>
      Cc: Haiyang Zhang <haiyangz@microsoft.com>
      Cc: Stephen Hemminger <sthemmin@microsoft.com>
      Signed-off-by: default avatarDexuan Cui <decui@microsoft.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ff53cc35
    • Cfir Cohen's avatar
      KVM: Fix UAF in nested posted interrupt processing · cc70f149
      Cfir Cohen authored
      commit c2dd5146 upstream.
      
      nested_get_vmcs12_pages() processes the posted_intr address in vmcs12. It
      caches the kmap()ed page object and pointer, however, it doesn't handle
      errors correctly: it's possible to cache a valid pointer, then release
      the page and later dereference the dangling pointer.
      
      I was able to reproduce with the following steps:
      
      1. Call vmlaunch with valid posted_intr_desc_addr but an invalid
      MSR_EFER. This causes nested_get_vmcs12_pages() to cache the kmap()ed
      pi_desc_page and pi_desc. Later the invalid EFER value fails
      check_vmentry_postreqs() which fails the first vmlaunch.
      
      2. Call vmlanuch with a valid EFER but an invalid posted_intr_desc_addr
      (I set it to 2G - 0x80). The second time we call nested_get_vmcs12_pages
      pi_desc_page is unmapped and released and pi_desc_page is set to NULL
      (the "shouldn't happen" clause). Due to the invalid
      posted_intr_desc_addr, kvm_vcpu_gpa_to_page() fails and
      nested_get_vmcs12_pages() returns. It doesn't return an error value so
      vmlaunch proceeds. Note that at this time we have a dangling pointer in
      vmx->nested.pi_desc and POSTED_INTR_DESC_ADDR in L0's vmcs.
      
      3. Issue an IPI in L2 guest code. This triggers a call to
      vmx_complete_nested_posted_interrupt() and pi_test_and_clear_on() which
      dereferences the dangling pointer.
      
      Vulnerable code requires nested and enable_apicv variables to be set to
      true. The host CPU must also support posted interrupts.
      
      Fixes: 5e2f30b7 "KVM: nVMX: get rid of nested_get_page()"
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarAndy Honig <ahonig@google.com>
      Signed-off-by: default avatarCfir Cohen <cfir@google.com>
      Reviewed-by: default avatarLiran Alon <liran.alon@oracle.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cc70f149
    • Eduardo Habkost's avatar
      kvm: x86: Add AMD's EX_CFG to the list of ignored MSRs · df4ee073
      Eduardo Habkost authored
      commit 0e1b869f upstream.
      
      Some guests OSes (including Windows 10) write to MSR 0xc001102c
      on some cases (possibly while trying to apply a CPU errata).
      Make KVM ignore reads and writes to that MSR, so the guest won't
      crash.
      
      The MSR is documented as "Execution Unit Configuration (EX_CFG)",
      at AMD's "BIOS and Kernel Developer's Guide (BKDG) for AMD Family
      15h Models 00h-0Fh Processors".
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarEduardo Habkost <ehabkost@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      df4ee073
    • Thomas Gleixner's avatar
      posix-timers: Fix division by zero bug · 2f8f9e28
      Thomas Gleixner authored
      commit 0e334db6 upstream.
      
      The signal delivery path of posix-timers can try to rearm the timer even if
      the interval is zero. That's handled for the common case (hrtimer) but not
      for alarm timers. In that case the forwarding function raises a division by
      zero exception.
      
      The handling for hrtimer based posix timers is wrong because it marks the
      timer as active despite the fact that it is stopped.
      
      Move the check from common_hrtimer_rearm() to posixtimer_rearm() to cure
      both issues.
      
      Reported-by: syzbot+9d38bedac9cc77b8ad5e@syzkaller.appspotmail.com
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: sboyd@kernel.org
      Cc: stable@vger.kernel.org
      Cc: syzkaller-bugs@googlegroups.com
      Link: http://lkml.kernel.org/r/alpine.DEB.2.21.1812171328050.1880@nanos.tec.linutronix.deSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2f8f9e28
    • Hans de Goede's avatar
      gpiolib-acpi: Only defer request_irq for GpioInt ACPI event handlers · 23572a68
      Hans de Goede authored
      commit e59f5e08 upstream.
      
      Commit 78d3a92e ("gpiolib-acpi: Register GpioInt ACPI event handlers
      from a late_initcall") deferred the entire acpi_gpiochip_request_interrupt
      call for each event resource.
      
      This means it also delays the gpiochip_request_own_desc(..., "ACPI:Event")
      call. This is a problem if some AML code reads the GPIO pin before we
      run the deferred acpi_gpiochip_request_interrupt, because in that case
      acpi_gpio_adr_space_handler() will already have called
      gpiochip_request_own_desc(..., "ACPI:OpRegion") causing the call from
      acpi_gpiochip_request_interrupt to fail with -EBUSY and we will fail to
      register an event handler.
      
      acpi_gpio_adr_space_handler is prepared for acpi_gpiochip_request_interrupt
      already having claimed the pin, but the other way around does not work.
      
      One example of a problem this causes, is the event handler for the OTG
      ID pin on a Prowise PT301 tablet not registering, keeping the port stuck
      in whatever mode it was in during boot and e.g. only allowing charging
      after a reboot.
      
      This commit fixes this by only deferring the request_irq call and the
      initial run of edge-triggered IRQs instead of deferring all of
      acpi_gpiochip_request_interrupt.
      
      Cc: stable@vger.kernel.org
      Fixes: 78d3a92e ("gpiolib-acpi: Register GpioInt ACPI event ...")
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Reviewed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Acked-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      23572a68
    • Christophe Leroy's avatar
      gpio: max7301: fix driver for use with CONFIG_VMAP_STACK · 07cfa7ac
      Christophe Leroy authored
      commit abf221d2 upstream.
      
      spi_read() and spi_write() require DMA-safe memory. When
      CONFIG_VMAP_STACK is selected, those functions cannot be used
      with buffers on stack.
      
      This patch replaces calls to spi_read() and spi_write() by
      spi_write_then_read() which doesn't require DMA-safe buffers.
      
      Fixes: 0c36ec31 ("gpio: gpio driver for max7301 SPI GPIO expander")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      07cfa7ac
    • Russell King's avatar
      mmc: omap_hsmmc: fix DMA API warning · 4d7a081d
      Russell King authored
      commit 0b479790 upstream.
      
      While booting with rootfs on MMC, the following warning is encountered
      on OMAP4430:
      
      omap-dma-engine 4a056000.dma-controller: DMA-API: mapping sg segment longer than device claims to support [len=69632] [max=65536]
      
      This is because the DMA engine has a default maximum segment size of 64K
      but HSMMC sets:
      
              mmc->max_blk_size = 512;       /* Block Length at max can be 1024 */
              mmc->max_blk_count = 0xFFFF;    /* No. of Blocks is 16 bits */
              mmc->max_req_size = mmc->max_blk_size * mmc->max_blk_count;
              mmc->max_seg_size = mmc->max_req_size;
      
      which ends up telling the block layer that we support a maximum segment
      size of 65535*512, which exceeds the advertised DMA engine capabilities.
      
      Fix this by clamping the maximum segment size to the lower of the
      maximum request size and of the DMA engine device used for either DMA
      channel.
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4d7a081d
    • Ulf Hansson's avatar
      mmc: core: Use a minimum 1600ms timeout when enabling CACHE ctrl · b097c443
      Ulf Hansson authored
      commit e3ae3401 upstream.
      
      Some eMMCs from Micron have been reported to need ~800 ms timeout, while
      enabling the CACHE ctrl after running sudden power failure tests. The
      needed timeout is greater than what the card specifies as its generic CMD6
      timeout, through the EXT_CSD register, hence the problem.
      
      Normally we would introduce a card quirk to extend the timeout for these
      specific Micron cards. However, due to the rather complicated debug process
      needed to find out the error, let's simply use a minimum timeout of 1600ms,
      the double of what has been reported, for all cards when enabling CACHE
      ctrl.
      Reported-by: default avatarSjoerd Simons <sjoerd.simons@collabora.co.uk>
      Reported-by: default avatarAndreas Dannenberg <dannenberg@ti.com>
      Reported-by: default avatarFaiz Abbas <faiz_abbas@ti.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b097c443
    • Ulf Hansson's avatar
      mmc: core: Allow BKOPS and CACHE ctrl even if no HPI support · 2b591835
      Ulf Hansson authored
      commit ba9f39a7 upstream.
      
      In commit 5320226a ("mmc: core: Disable HPI for certain Hynix eMMC
      cards"), then intent was to prevent HPI from being used for some eMMC
      cards, which didn't properly support it. However, that went too far, as
      even BKOPS and CACHE ctrl became prevented. Let's restore those parts and
      allow BKOPS and CACHE ctrl even if HPI isn't supported.
      
      Fixes: 5320226a ("mmc: core: Disable HPI for certain Hynix eMMC cards")
      Cc: Pratibhasagar V <pratibha@codeaurora.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2b591835
    • Ulf Hansson's avatar
      mmc: core: Reset HPI enabled state during re-init and in case of errors · 8af6fad4
      Ulf Hansson authored
      commit a0741ba4 upstream.
      
      During a re-initialization of the eMMC card, we may fail to re-enable HPI.
      In these cases, that isn't properly reflected in the card->ext_csd.hpi_en
      bit, as it keeps being set. This may cause following attempts to use HPI,
      even if's not enabled. Let's fix this!
      
      Fixes: eb0d8f13 ("mmc: core: support HPI send command")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8af6fad4
    • Jens Axboe's avatar
      scsi: sd: use mempool for discard special page · fe646761
      Jens Axboe authored
      commit 61cce6f6 upstream.
      
      When boxes are run near (or to) OOM, we have a problem with the discard
      page allocation in sd. If we fail allocating the special page, we return
      busy, and it'll get retried. But since ordering is honored for dispatch
      requests, we can keep retrying this same IO and failing. Behind that IO
      could be requests that want to free memory, but they never get the
      chance. This means you get repeated spews of traces like this:
      
      [1201401.625972] Call Trace:
      [1201401.631748]  dump_stack+0x4d/0x65
      [1201401.639445]  warn_alloc+0xec/0x190
      [1201401.647335]  __alloc_pages_slowpath+0xe84/0xf30
      [1201401.657722]  ? get_page_from_freelist+0x11b/0xb10
      [1201401.668475]  ? __alloc_pages_slowpath+0x2e/0xf30
      [1201401.679054]  __alloc_pages_nodemask+0x1f9/0x210
      [1201401.689424]  alloc_pages_current+0x8c/0x110
      [1201401.699025]  sd_setup_write_same16_cmnd+0x51/0x150
      [1201401.709987]  sd_init_command+0x49c/0xb70
      [1201401.719029]  scsi_setup_cmnd+0x9c/0x160
      [1201401.727877]  scsi_queue_rq+0x4d9/0x610
      [1201401.736535]  blk_mq_dispatch_rq_list+0x19a/0x360
      [1201401.747113]  blk_mq_sched_dispatch_requests+0xff/0x190
      [1201401.758844]  __blk_mq_run_hw_queue+0x95/0xa0
      [1201401.768653]  blk_mq_run_work_fn+0x2c/0x30
      [1201401.777886]  process_one_work+0x14b/0x400
      [1201401.787119]  worker_thread+0x4b/0x470
      [1201401.795586]  kthread+0x110/0x150
      [1201401.803089]  ? rescuer_thread+0x320/0x320
      [1201401.812322]  ? kthread_park+0x90/0x90
      [1201401.820787]  ? do_syscall_64+0x53/0x150
      [1201401.829635]  ret_from_fork+0x29/0x40
      
      Ensure that the discard page allocation has a mempool backing, so we
      know we can make progress.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fe646761
    • Jörgen Storvist's avatar
      USB: serial: option: add Telit LN940 series · 61c1a4a5
      Jörgen Storvist authored
      commit 28a86092 upstream.
      
      Added USB serial option driver support for Telit LN940 series cellular
      modules. Covering both QMI and MBIM modes.
      
      usb-devices output (0x1900):
      T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 21 Spd=480 MxCh= 0
      D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=1bc7 ProdID=1900 Rev=03.10
      S:  Manufacturer=Telit
      S:  Product=Telit LN940 Mobile Broadband
      S:  SerialNumber=0123456789ABCDEF
      C:  #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA
      I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
      I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      
      usb-devices output (0x1901):
      T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 20 Spd=480 MxCh= 0
      D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=1bc7 ProdID=1901 Rev=03.10
      S:  Manufacturer=Telit
      S:  Product=Telit LN940 Mobile Broadband
      S:  SerialNumber=0123456789ABCDEF
      C:  #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
      I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 4 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
      I:  If#= 5 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
      Signed-off-by: default avatarJörgen Storvist <jorgen.storvist@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      61c1a4a5
    • Jörgen Storvist's avatar
      USB: serial: option: add Fibocom NL668 series · 4363aa8f
      Jörgen Storvist authored
      commit 30360224 upstream.
      
      Added USB serial option driver support for Fibocom NL668 series cellular
      modules. Reserved USB endpoints 4, 5 and 6 for network + ADB interfaces.
      
      usb-devices output (QMI mode)
      T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 16 Spd=480 MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=1508 ProdID=1001 Rev=03.18
      S:  Manufacturer=Nodecom NL668 Modem
      S:  Product=Nodecom NL668-CN Modem
      S:  SerialNumber=
      C:  #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
      I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
      I:  If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
      
      usb-devices output (ECM mode)
      T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 17 Spd=480 MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=1508 ProdID=1001 Rev=03.18
      S:  Manufacturer=Nodecom NL668 Modem
      S:  Product=Nodecom NL668-CN Modem
      S:  SerialNumber=
      C:  #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA
      I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 4 Alt= 0 #EPs= 1 Cls=02(commc) Sub=06 Prot=00 Driver=cdc_ether
      I:  If#= 5 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether
      I:  If#= 6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
      Signed-off-by: default avatarJörgen Storvist <jorgen.storvist@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4363aa8f
    • Jörgen Storvist's avatar
      USB: serial: option: add Simcom SIM7500/SIM7600 (MBIM mode) · 4497e8fa
      Jörgen Storvist authored
      commit cc6730df upstream.
      
      Added USB serial option driver support for Simcom SIM7500/SIM7600 series
      cellular modules exposing MBIM interface (VID 0x1e0e,PID 0x9003)
      
      T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 14 Spd=480 MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=1e0e ProdID=9003 Rev=03.18
      S:  Manufacturer=SimTech, Incorporated
      S:  Product=SimTech, Incorporated
      S:  SerialNumber=0123456789ABCDEF
      C:  #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA
      I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 5 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
      I:  If#= 6 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
      Signed-off-by: default avatarJörgen Storvist <jorgen.storvist@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4497e8fa
    • Tore Anderson's avatar
      USB: serial: option: add HP lt4132 · 0b3b6c5b
      Tore Anderson authored
      commit d57ec3c8 upstream.
      
      The HP lt4132 is a rebranded Huawei ME906s-158 LTE modem.
      
      The interface with protocol 0x16 is "CDC ECM & NCM" according to the *.inf
      files included with the Windows driver. Attaching the option driver to it
      doesn't result in a /dev/ttyUSB* device being created, so I've excluded it.
      Note that it is also excluded for corresponding Huawei-branded devices, cf.
      commit d544db29 ("USB: support new huawei devices in option.c").
      
      T:  Bus=01 Lev=01 Prnt=01 Port=02 Cnt=02 Dev#=  3 Spd=480 MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=ff MxPS=64 #Cfgs=  3
      P:  Vendor=03f0 ProdID=a31d Rev=01.02
      S:  Manufacturer=HP Inc.
      S:  Product=HP lt4132 LTE/HSPA+ 4G Module
      S:  SerialNumber=0123456789ABCDEF
      C:  #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=2mA
      I:  If#=0x0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=06 Prot=10 Driver=option
      I:  If#=0x1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=13 Driver=option
      I:  If#=0x2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=12 Driver=option
      I:  If#=0x3 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=06 Prot=16 Driver=(none)
      I:  If#=0x4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=14 Driver=option
      I:  If#=0x5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=1b Driver=option
      
      T:  Bus=01 Lev=01 Prnt=01 Port=02 Cnt=02 Dev#=  3 Spd=480 MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=ff MxPS=64 #Cfgs=  3
      P:  Vendor=03f0 ProdID=a31d Rev=01.02
      S:  Manufacturer=HP Inc.
      S:  Product=HP lt4132 LTE/HSPA+ 4G Module
      S:  SerialNumber=0123456789ABCDEF
      C:  #Ifs= 7 Cfg#= 2 Atr=a0 MxPwr=2mA
      I:  If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=06 Prot=00 Driver=cdc_ether
      I:  If#=0x1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=06 Prot=00 Driver=cdc_ether
      I:  If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=06 Prot=10 Driver=option
      I:  If#=0x3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=13 Driver=option
      I:  If#=0x4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=12 Driver=option
      I:  If#=0x5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=14 Driver=option
      I:  If#=0x6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=1b Driver=option
      
      T:  Bus=01 Lev=01 Prnt=01 Port=02 Cnt=02 Dev#=  3 Spd=480 MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=ff MxPS=64 #Cfgs=  3
      P:  Vendor=03f0 ProdID=a31d Rev=01.02
      S:  Manufacturer=HP Inc.
      S:  Product=HP lt4132 LTE/HSPA+ 4G Module
      S:  SerialNumber=0123456789ABCDEF
      C:  #Ifs= 3 Cfg#= 3 Atr=a0 MxPwr=2mA
      I:  If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
      I:  If#=0x1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
      I:  If#=0x2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=14 Driver=option
      Signed-off-by: default avatarTore Anderson <tore@fud.no>
      Cc: stable@vger.kernel.org
      [ johan: drop id defines ]
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0b3b6c5b
    • Jörgen Storvist's avatar
      USB: serial: option: add GosunCn ZTE WeLink ME3630 · ed101ab6
      Jörgen Storvist authored
      commit 70a7444c upstream.
      
      Added USB serial option driver support for GosunCn ZTE WeLink ME3630
      series cellular modules for USB modes ECM/NCM and MBIM.
      
      usb-devices output MBIM mode:
      T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 10 Spd=480 MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=19d2 ProdID=0602 Rev=03.18
      S:  Manufacturer=Android
      S:  Product=Android
      S:  SerialNumber=
      C:  #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA
      I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 3 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
      I:  If#= 4 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
      
      usb-devices output ECM/NCM mode:
      T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 11 Spd=480 MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=19d2 ProdID=1476 Rev=03.18
      S:  Manufacturer=Android
      S:  Product=Android
      S:  SerialNumber=
      C:  #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA
      I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 3 Alt= 0 #EPs= 1 Cls=02(commc) Sub=06 Prot=00 Driver=cdc_ether
      I:  If#= 4 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether
      Signed-off-by: default avatarJörgen Storvist <jorgen.storvist@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ed101ab6
    • Nicolas Saenz Julienne's avatar
      USB: xhci: fix 'broken_suspend' placement in struct xchi_hcd · 4aa9cf83
      Nicolas Saenz Julienne authored
      commit 2419f30a upstream.
      
      As commented in the struct's definition there shouldn't be anything
      underneath its 'priv[0]' member as it would break some macros.
      
      The patch converts the broken_suspend into a bit-field and relocates it
      next to to the rest of bit-fields.
      
      Fixes: a7d57abc ("xhci: workaround CSS timeout on AMD SNPS 3.0 xHC")
      Reported-by: default avatarOliver Neukum  <oneukum@suse.com>
      Signed-off-by: default avatarNicolas Saenz Julienne <nsaenzjulienne@suse.de>
      Acked-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4aa9cf83
    • Mathias Nyman's avatar
      xhci: Don't prevent USB2 bus suspend in state check intended for USB3 only · 2ab5db61
      Mathias Nyman authored
      commit 45f750c1 upstream.
      
      The code to prevent a bus suspend if a USB3 port was still in link training
      also reacted to USB2 port polling state.
      This caused bus suspend to busyloop in some cases.
      USB2 polling state is different from USB3, and should not prevent bus
      suspend.
      
      Limit the USB3 link training state check to USB3 root hub ports only.
      The origial commit went to stable so this need to be applied there as well
      
      Fixes: 2f31a67f ("usb: xhci: Prevent bus suspend if a port connect change or polling state is detected")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2ab5db61
    • Hui Peng's avatar
      USB: hso: Fix OOB memory access in hso_probe/hso_get_config_data · 49be8dc5
      Hui Peng authored
      commit 5146f95d upstream.
      
      The function hso_probe reads if_num from the USB device (as an u8) and uses
      it without a length check to index an array, resulting in an OOB memory read
      in hso_probe or hso_get_config_data.
      
      Add a length check for both locations and updated hso_probe to bail on
      error.
      
      This issue has been assigned CVE-2018-19985.
      Reported-by: default avatarHui Peng <benquike@gmail.com>
      Reported-by: default avatarMathias Payer <mathias.payer@nebelwelt.net>
      Signed-off-by: default avatarHui Peng <benquike@gmail.com>
      Signed-off-by: default avatarMathias Payer <mathias.payer@nebelwelt.net>
      Reviewed-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      49be8dc5
    • Dan Carpenter's avatar
      cifs: integer overflow in in SMB2_ioctl() · 3845c736
      Dan Carpenter authored
      commit 2d204ee9 upstream
      
      The "le32_to_cpu(rsp->OutputOffset) + *plen" addition can overflow and
      wrap around to a smaller value which looks like it would lead to an
      information leak.
      
      Fixes: 4a72dafa ("SMB2 FSCTL and IOCTL worker function")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      Reviewed-by: default avatarAurelien Aptel <aaptel@suse.com>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: default avatarSudip Mukherjee <sudipm.mukherjee@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3845c736
    • Jiri Olsa's avatar
      perf record: Synthesize features before events in pipe mode · 0d9b5136
      Jiri Olsa authored
      [ Upstream commit a2015516 ]
      
      We need to synthesize events first, because some features works on top
      of them (on report side).
      Signed-off-by: default avatarJiri Olsa <jolsa@kernel.org>
      Tested-by: default avatarStephane Eranian <eranian@google.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20180314092205.23291-1-jolsa@kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      0d9b5136
    • Bart Van Assche's avatar
      ib_srpt: Fix a use-after-free in __srpt_close_all_ch() · 179c8da7
      Bart Van Assche authored
      commit 14d15c2b upstream
      
      BUG: KASAN: use-after-free in srpt_set_enabled+0x1a9/0x1e0 [ib_srpt]
      Read of size 4 at addr ffff8801269d23f8 by task check/29726
      
      CPU: 4 PID: 29726 Comm: check Not tainted 4.18.0-rc2-dbg+ #4
      Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
      Call Trace:
       dump_stack+0xa4/0xf5
       print_address_description+0x6f/0x270
       kasan_report+0x241/0x360
       __asan_load4+0x78/0x80
       srpt_set_enabled+0x1a9/0x1e0 [ib_srpt]
       srpt_tpg_enable_store+0xb8/0x120 [ib_srpt]
       configfs_write_file+0x14e/0x1d0 [configfs]
       __vfs_write+0xd2/0x3b0
       vfs_write+0x101/0x270
       ksys_write+0xab/0x120
       __x64_sys_write+0x43/0x50
       do_syscall_64+0x77/0x230
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x7f235cfe6154
      
      Fixes: aaf45bd8 ("IB/srpt: Detect session shutdown reliably")
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@wdc.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: default avatarSudip Mukherjee <sudipm.mukherjee@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      179c8da7
    • Richard Weinberger's avatar
      ubifs: Fix directory size calculation for symlinks · 56303ade
      Richard Weinberger authored
      commit 00ee8b60 upstream
      
      We have to account the name of the symlink and not the target length.
      
      Fixes: ca7f85be ("ubifs: Add support for encrypted symlinks")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      Signed-off-by: default avatarSudip Mukherjee <sudipm.mukherjee@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      56303ade
    • Daniel Mack's avatar
      ASoC: sta32x: set ->component pointer in private struct · 2e598102
      Daniel Mack authored
      commit 747df197 upstream
      
      The ESD watchdog code in sta32x_watchdog() dereferences the pointer
      which is never assigned.
      
      This is a regression from a1be4cea ("ASoC: sta32x: Convert to direct
      regmap API usage.") which went unnoticed since nobody seems to use that ESD
      workaround.
      
      Fixes: a1be4cea ("ASoC: sta32x: Convert to direct regmap API usage.")
      Signed-off-by: default avatarDaniel Mack <daniel@zonque.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSudip Mukherjee <sudipm.mukherjee@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2e598102
    • Mikulas Patocka's avatar
      block: fix infinite loop if the device loses discard capability · 07eae146
      Mikulas Patocka authored
      [ Upstream commit b88aef36 ]
      
      If __blkdev_issue_discard is in progress and a device mapper device is
      reloaded with a table that doesn't support discard,
      q->limits.max_discard_sectors is set to zero. This results in infinite
      loop in __blkdev_issue_discard.
      
      This patch checks if max_discard_sectors is zero and aborts with
      -EOPNOTSUPP.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Tested-by: default avatarZdenek Kabelac <mpatocka@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      07eae146
    • Jens Axboe's avatar
      block: break discard submissions into the user defined size · 1e9290ca
      Jens Axboe authored
      [ Upstream commit af097f5d ]
      
      Don't build discards bigger than what the user asked for, if the
      user decided to limit the size by writing to 'discard_max_bytes'.
      Reviewed-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: default avatarOmar Sandoval <osandov@fb.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1e9290ca
  2. 21 Dec, 2018 10 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.14.90 · 592f5569
      Greg Kroah-Hartman authored
      592f5569
    • Nicolas Schichan's avatar
      bpf, arm: fix emit_ldx_r and emit_mov_i using TMP_REG_1 · ad962d20
      Nicolas Schichan authored
      emit_ldx_r() and emit_a32_mov_i() were both using TMP_REG_1 and
      clashing with each other. Using TMP_REG_2 in emit_ldx_r() fixes
      the issue.
      
      Fixes: ec19e02b ("ARM: net: bpf: fix LDX instructions")
      Cc: Russell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarNicolas Schichan <nschichan@freebox.fr>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ad962d20
    • Trent Piepho's avatar
      rtc: snvs: Add timeouts to avoid kernel lockups · f1e1eb5c
      Trent Piepho authored
      [ Upstream commit cd7f3a24 ]
      
      In order to read correctly from asynchronously updated RTC registers,
      it's necessary to read repeatedly until their values do not change from
      read to read.  It's also necessary to wait for three RTC clock ticks for
      certain operations.  There are no timeouts in this code and these
      operations could possibly loop forever.
      
      To avoid kernel hangs, put in timeouts.
      
      The iMX7d can be configured to stop the SRTC on a tamper event, which
      will lockup the kernel inside this driver as described above.
      
      These hangs can happen when running under qemu, which doesn't emulate
      the SNVS RTC, though currently the driver will refuse to load on qemu
      due to a timeout in the driver probe method.
      
      It could also happen if the SRTC block where somehow placed into reset
      or the slow speed clock that drives the SRTC counter (but not the CPU)
      were to stop.
      
      The symptoms on a two core iMX7d are a work queue hang on
      rtc_timer_do_work(), which eventually blocks a systemd fsnotify
      operation that triggers a work queue flush, causing systemd to hang and
      thus causing all services that should be started by systemd, like a
      console getty, to fail to start or stop.
      
      Also optimize the wait code to wait less.  It only needs to wait for the
      clock to advance three ticks, not to see it change three times.
      
      Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Cc: Fabio Estevam <fabio.estevam@nxp.com>
      Cc: Shawn Guo <shawn.guo@linaro.org>
      Cc: Bryan O'Donoghue <pure.logic@nexus-software.ie>
      Signed-off-by: default avatarTrent Piepho <tpiepho@impinj.com>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@bootlin.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f1e1eb5c
    • Israel Rukshin's avatar
      nvmet-rdma: fix response use after free · 60e3480e
      Israel Rukshin authored
      [ Upstream commit d7dcdf9d ]
      
      nvmet_rdma_release_rsp() may free the response before using it at error
      flow.
      
      Fixes: 8407879c ("nvmet-rdma: fix possible bogus dereference under heavy load")
      Signed-off-by: default avatarIsrael Rukshin <israelr@mellanox.com>
      Reviewed-by: default avatarSagi Grimberg <sagi@grimberg.me>
      Reviewed-by: default avatarMax Gurtovoy <maxg@mellanox.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      60e3480e
    • Masahiro Yamada's avatar
      i2c: uniphier-f: fix violation of tLOW requirement for Fast-mode · 07d4f1c4
      Masahiro Yamada authored
      [ Upstream commit ece27a33 ]
      
      Currently, the clock duty is set as tLOW/tHIGH = 1/1. For Fast-mode,
      tLOW is set to 1.25 us while the I2C spec requires tLOW >= 1.3 us.
      
      tLOW/tHIGH = 5/4 would meet both Standard-mode and Fast-mode:
        Standard-mode: tLOW = 5.56 us, tHIGH = 4.44 us
        Fast-mode:     tLOW = 1.39 us, tHIGH = 1.11 us
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      07d4f1c4
    • Masahiro Yamada's avatar
      i2c: uniphier: fix violation of tLOW requirement for Fast-mode · 90265a60
      Masahiro Yamada authored
      [ Upstream commit 8469636a ]
      
      Currently, the clock duty is set as tLOW/tHIGH = 1/1. For Fast-mode,
      tLOW is set to 1.25 us while the I2C spec requires tLOW >= 1.3 us.
      
      tLOW/tHIGH = 5/4 would meet both Standard-mode and Fast-mode:
        Standard-mode: tLOW = 5.56 us, tHIGH = 4.44 us
        Fast-mode:     tLOW = 1.39 us, tHIGH = 1.11 us
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      90265a60
    • Hans de Goede's avatar
      i2c: scmi: Fix probe error on devices with an empty SMB0001 ACPI device node · c39910b5
      Hans de Goede authored
      [ Upstream commit 0544ee4b ]
      
      Some AMD based HP laptops have a SMB0001 ACPI device node which does not
      define any methods.
      
      This leads to the following error in dmesg:
      
      [    5.222731] cmi: probe of SMB0001:00 failed with error -5
      
      This commit makes acpi_smbus_cmi_add() return -ENODEV instead in this case
      silencing the error. In case of a failure of the i2c_add_adapter() call
      this commit now propagates the error from that call instead of -EIO.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c39910b5
    • Adamski, Krzysztof (Nokia - PL/Wroclaw)'s avatar
      i2c: axxia: properly handle master timeout · 4bdfff5c
      [ Upstream commit 6c7f25ca ]
      
      According to Intel (R) Axxia TM Lionfish Communication Processor
      Peripheral Subsystem Hardware Reference Manual, the AXXIA I2C module
      have a programmable Master Wait Timer, which among others, checks the
      time between commands send in manual mode. When a timeout (25ms) passes,
      TSS bit is set in Master Interrupt Status register and a Stop command is
      issued by the hardware.
      
      The axxia_i2c_xfer(), does not properly handle this situation, however.
      For each message a separate axxia_i2c_xfer_msg() is called and this
      function incorrectly assumes that any interrupt might happen only when
      waiting for completion. This is mostly correct but there is one
      exception - a master timeout can trigger if enough time has passed
      between individual transfers. It will, by definition, happen between
      transfers when the interrupts are disabled by the code. If that happens,
      the hardware issues Stop command.
      
      The interrupt indicating timeout will not be triggered as soon as we
      enable them since the Master Interrupt Status is cleared when master
      mode is entered again (which happens before enabling irqs) meaning this
      error is lost and the transfer is continued even though the Stop was
      issued on the bus. The subsequent operations completes without error but
      a bogus value (0xFF in case of read) is read as the client device is
      confused because aborted transfer. No error is returned from
      master_xfer() making caller believe that a valid value was read.
      
      To fix the problem, the TSS bit (indicating timeout) in Master Interrupt
      Status register is checked before each transfer. If it is set, there was
      a timeout before this transfer and (as described above) the hardware
      already issued Stop command so the transaction should be aborted thus
      -ETIMEOUT is returned from the master_xfer() callback. In order to be
      sure no timeout was issued we can't just read the status just before
      starting new transaction as there will always be a small window of time
      (few CPU cycles at best) where this might still happen. For this reason
      we have to temporally disable the timer before checking for TSS bit.
      Disabling it will, however, clear the TSS bit so in order to preserve
      that information, we have to read it in ISR so we have to ensure that
      the TSS interrupt is not masked between transfers of one transaction.
      There is no need to call bus recovery or controller reinitialization if
      that happens so it's skipped.
      Signed-off-by: default avatarKrzysztof Adamski <krzysztof.adamski@nokia.com>
      Reviewed-by: default avatarAlexander Sverdlin <alexander.sverdlin@nokia.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      4bdfff5c
    • Ido Schimmel's avatar
      mlxsw: spectrum_switchdev: Fix VLAN device deletion via ioctl · 73c821e3
      Ido Schimmel authored
      [ Upstream commit 993107fe ]
      
      When deleting a VLAN device using an ioctl the netdev is unregistered
      before the VLAN filter is updated via ndo_vlan_rx_kill_vid(). It can
      lead to a use-after-free in mlxsw in case the VLAN device is deleted
      while being enslaved to a bridge.
      
      The reason for the above is that when mlxsw receives the CHANGEUPPER
      event, it wrongly assumes that the VLAN device is no longer its upper
      and thus destroys the internal representation of the bridge port despite
      the reference count being non-zero.
      
      Fix this by checking if the VLAN device is our upper using its real
      device. In net-next I'm going to remove this trick and instead make
      mlxsw completely agnostic to the order of the events.
      
      Fixes: c57529e1 ("mlxsw: spectrum: Replace vPorts with Port-VLAN")
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: default avatarPetr Machata <petrm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      73c821e3
    • Stefan Hajnoczi's avatar
      vhost/vsock: fix reset orphans race with close timeout · 7e43eec4
      Stefan Hajnoczi authored
      [ Upstream commit c38f57da ]
      
      If a local process has closed a connected socket and hasn't received a
      RST packet yet, then the socket remains in the table until a timeout
      expires.
      
      When a vhost_vsock instance is released with the timeout still pending,
      the socket is never freed because vhost_vsock has already set the
      SOCK_DONE flag.
      
      Check if the close timer is pending and let it close the socket.  This
      prevents the race which can leak sockets.
      Reported-by: default avatarMaximilian Riemensberger <riemensberger@cadami.net>
      Cc: Graham Whaley <graham.whaley@gmail.com>
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7e43eec4