1. 13 Dec, 2018 25 commits
    • Linus Torvalds's avatar
      unifdef: use memcpy instead of strncpy · 37370fad
      Linus Torvalds authored
      commit 38c7b224ce22c25fed04007839edf974bd13439d upstream.
      
      New versions of gcc reasonably warn about the odd pattern of
      
      	strncpy(p, q, strlen(q));
      
      which really doesn't make sense: the strncpy() ends up being just a slow
      and odd way to write memcpy() in this case.
      
      There was a comment about _why_ the code used strncpy - to avoid the
      terminating NUL byte, but memcpy does the same and avoids the warning.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      37370fad
    • Guenter Roeck's avatar
      kobject: Replace strncpy with memcpy · 204a765e
      Guenter Roeck authored
      commit 77d2a24b6107bd9b3bf2403a65c1428a9da83dd0 upstream.
      
      gcc 8.1.0 complains:
      
      lib/kobject.c:128:3: warning:
      	'strncpy' output truncated before terminating nul copying as many
      	bytes from a string as its length [-Wstringop-truncation]
      lib/kobject.c: In function 'kobject_get_path':
      lib/kobject.c:125:13: note: length computed here
      
      Using strncpy() is indeed less than perfect since the length of data to
      be copied has already been determined with strlen(). Replace strncpy()
      with memcpy() to address the warning and optimize the code a little.
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      204a765e
    • Stephen Rothwell's avatar
      disable stringop truncation warnings for now · 62ff5946
      Stephen Rothwell authored
      commit 217c3e0196758662aa0429863b09d1c13da1c5d6 upstream.
      
      They are too noisy
      Signed-off-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      62ff5946
    • Arnd Bergmann's avatar
      exec: avoid gcc-8 warning for get_task_comm · 2ac36cc6
      Arnd Bergmann authored
      commit 3756f640 upstream.
      
      gcc-8 warns about using strncpy() with the source size as the limit:
      
        fs/exec.c:1223:32: error: argument to 'sizeof' in 'strncpy' call is the same expression as the source; did you mean to use the size of the destination? [-Werror=sizeof-pointer-memaccess]
      
      This is indeed slightly suspicious, as it protects us from source
      arguments without NUL-termination, but does not guarantee that the
      destination is terminated.
      
      This keeps the strncpy() to ensure we have properly padded target
      buffer, but ensures that we use the correct length, by passing the
      actual length of the destination buffer as well as adding a build-time
      check to ensure it is exactly TASK_COMM_LEN.
      
      There are only 23 callsites which I all reviewed to ensure this is
      currently the case.  We could get away with doing only the check or
      passing the right length, but it doesn't hurt to do both.
      
      Link: http://lkml.kernel.org/r/20171205151724.1764896-1-arnd@arndb.deSigned-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Suggested-by: default avatarKees Cook <keescook@chromium.org>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Acked-by: default avatarIngo Molnar <mingo@kernel.org>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Serge Hallyn <serge@hallyn.com>
      Cc: James Morris <james.l.morris@oracle.com>
      Cc: Aleksa Sarai <asarai@suse.de>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Frederic Weisbecker <frederic@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2ac36cc6
    • Xiongfeng Wang's avatar
      Kbuild: suppress packed-not-aligned warning for default setting only · 5b8cc588
      Xiongfeng Wang authored
      commit 321cb030 upstream.
      
      gcc-8 reports many -Wpacked-not-aligned warnings. The below are some
      examples.
      
      ./include/linux/ceph/msgr.h:67:1: warning: alignment 1 of 'struct
      ceph_entity_addr' is less than 8 [-Wpacked-not-aligned]
       } __attribute__ ((packed));
      
      ./include/linux/ceph/msgr.h:67:1: warning: alignment 1 of 'struct
      ceph_entity_addr' is less than 8 [-Wpacked-not-aligned]
       } __attribute__ ((packed));
      
      ./include/linux/ceph/msgr.h:67:1: warning: alignment 1 of 'struct
      ceph_entity_addr' is less than 8 [-Wpacked-not-aligned]
       } __attribute__ ((packed));
      
      This patch suppresses this kind of warnings for default setting.
      Signed-off-by: default avatarXiongfeng Wang <xiongfeng.wang@linaro.org>
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5b8cc588
    • YueHaibing's avatar
      misc: mic/scif: fix copy-paste error in scif_create_remote_lookup · 1cbec2e9
      YueHaibing authored
      commit 6484a677294aa5d08c0210f2f387ebb9be646115 upstream.
      
      gcc '-Wunused-but-set-variable' warning:
      
      drivers/misc/mic/scif/scif_rma.c: In function 'scif_create_remote_lookup':
      drivers/misc/mic/scif/scif_rma.c:373:25: warning:
       variable 'vmalloc_num_pages' set but not used [-Wunused-but-set-variable]
      
      'vmalloc_num_pages' should be used to determine if the address is
      within the vmalloc range.
      
      Fixes: ba612aa8 ("misc: mic: SCIF memory registration and unregistration")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1cbec2e9
    • Michael Niewöhner's avatar
      usb: core: quirks: add RESET_RESUME quirk for Cherry G230 Stream series · 1ddbdbd3
      Michael Niewöhner authored
      commit effd14f66cc1ef6701a19c5a56e39c35f4d395a5 upstream.
      
      Cherry G230 Stream 2.0 (G85-231) and 3.0 (G85-232) need this quirk to
      function correctly. This fixes a but where double pressing numlock locks
      up the device completely with need to replug the keyboard.
      Signed-off-by: default avatarMichael Niewöhner <linux@mniewoehner.de>
      Tested-by: default avatarMichael Niewöhner <linux@mniewoehner.de>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1ddbdbd3
    • Kai-Heng Feng's avatar
      USB: usb-storage: Add new IDs to ums-realtek · 9398e420
      Kai-Heng Feng authored
      commit a84a1bcc992f0545a51d2e120b8ca2ef20e2ea97 upstream.
      
      There are two new Realtek card readers require ums-realtek to work
      correctly.
      
      Add the new IDs to support them.
      Signed-off-by: default avatarKai-Heng Feng <kai.heng.feng@canonical.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9398e420
    • Josef Bacik's avatar
      btrfs: release metadata before running delayed refs · fed44f07
      Josef Bacik authored
      We want to release the unused reservation we have since it refills the
      delayed refs reserve, which will make everything go smoother when
      running the delayed refs if we're short on our reservation.
      
      CC: stable@vger.kernel.org # 4.4+
      Reviewed-by: default avatarOmar Sandoval <osandov@fb.com>
      Reviewed-by: default avatarLiu Bo <bo.liu@linux.alibaba.com>
      Reviewed-by: default avatarNikolay Borisov <nborisov@suse.com>
      Signed-off-by: default avatarJosef Bacik <josef@toxicpanda.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      fed44f07
    • Richard Genoud's avatar
      dmaengine: at_hdmac: fix module unloading · d27f7797
      Richard Genoud authored
      commit 77e75fda94d2ebb86aa9d35fb1860f6395bf95de upstream.
      
      of_dma_controller_free() was not called on module onloading.
      This lead to a soft lockup:
      watchdog: BUG: soft lockup - CPU#0 stuck for 23s!
      Modules linked in: at_hdmac [last unloaded: at_hdmac]
      when of_dma_request_slave_channel() tried to call ofdma->of_dma_xlate().
      
      Cc: stable@vger.kernel.org
      Fixes: bbe89c8e ("at_hdmac: move to generic DMA binding")
      Acked-by: default avatarLudovic Desroches <ludovic.desroches@microchip.com>
      Signed-off-by: default avatarRichard Genoud <richard.genoud@gmail.com>
      Signed-off-by: default avatarVinod Koul <vkoul@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d27f7797
    • Richard Genoud's avatar
      dmaengine: at_hdmac: fix memory leak in at_dma_xlate() · ec3eeb34
      Richard Genoud authored
      commit 98f5f932254b88ce828bc8e4d1642d14e5854caa upstream.
      
      The leak was found when opening/closing a serial port a great number of
      time, increasing kmalloc-32 in slabinfo.
      
      Each time the port was opened, dma_request_slave_channel() was called.
      Then, in at_dma_xlate(), atslave was allocated with devm_kzalloc() and
      never freed. (Well, it was free at module unload, but that's not what we
      want).
      So, here, kzalloc is more suited for the job since it has to be freed in
      atc_free_chan_resources().
      
      Cc: stable@vger.kernel.org
      Fixes: bbe89c8e ("at_hdmac: move to generic DMA binding")
      Reported-by: default avatarMario Forner <m.forner@be4energy.com>
      Suggested-by: default avatarAlexandre Belloni <alexandre.belloni@bootlin.com>
      Acked-by: default avatarAlexandre Belloni <alexandre.belloni@bootlin.com>
      Acked-by: default avatarLudovic Desroches <ludovic.desroches@microchip.com>
      Signed-off-by: default avatarRichard Genoud <richard.genoud@gmail.com>
      Signed-off-by: default avatarVinod Koul <vkoul@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ec3eeb34
    • Pan Bian's avatar
      ext2: fix potential use after free · 89ed5b72
      Pan Bian authored
      commit ecebf55d27a11538ea84aee0be643dd953f830d5 upstream.
      
      The function ext2_xattr_set calls brelse(bh) to drop the reference count
      of bh. After that, bh may be freed. However, following brelse(bh),
      it reads bh->b_data via macro HDR(bh). This may result in a
      use-after-free bug. This patch moves brelse(bh) after reading field.
      
      CC: stable@vger.kernel.org
      Signed-off-by: default avatarPan Bian <bianpan2016@163.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      89ed5b72
    • Takashi Iwai's avatar
      ALSA: sparc: Fix invalid snd_free_pages() at error path · 4d5f99ec
      Takashi Iwai authored
      commit 9a20332ab373b1f8f947e0a9c923652b32dab031 upstream.
      
      Some spurious calls of snd_free_pages() have been overlooked and
      remain in the error paths of sparc cs4231 driver code.  Since
      runtime->dma_area is managed by the PCM core helper, we shouldn't
      release manually.
      
      Drop the superfluous calls.
      Reviewed-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4d5f99ec
    • Takashi Iwai's avatar
      ALSA: control: Fix race between adding and removing a user element · 73f607ac
      Takashi Iwai authored
      commit e1a7bfe3807974e66f971f2589d4e0197ec0fced upstream.
      
      The procedure for adding a user control element has some window opened
      for race against the concurrent removal of a user element.  This was
      caught by syzkaller, hitting a KASAN use-after-free error.
      
      This patch addresses the bug by wrapping the whole procedure to add a
      user control element with the card->controls_rwsem, instead of only
      around the increment of card->user_ctl_count.
      
      This required a slight code refactoring, too.  The function
      snd_ctl_add() is split to two parts: a core function to add the
      control element and a part calling it.  The former is called from the
      function for adding a user control element inside the controls_rwsem.
      
      One change to be noted is that snd_ctl_notify() for adding a control
      element gets called inside the controls_rwsem as well while it was
      called outside the rwsem.  But this should be OK, as snd_ctl_notify()
      takes another (finer) rwlock instead of rwsem, and the call of
      snd_ctl_notify() inside rwsem is already done in another code path.
      
      Reported-by: syzbot+dc09047bce3820621ba2@syzkaller.appspotmail.com
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      73f607ac
    • Takashi Iwai's avatar
      ALSA: ac97: Fix incorrect bit shift at AC97-SPSA control write · a71ca61f
      Takashi Iwai authored
      commit 7194eda1ba0872d917faf3b322540b4f57f11ba5 upstream.
      
      The function snd_ac97_put_spsa() gets the bit shift value from the
      associated private_value, but it extracts too much; the current code
      extracts 8 bit values in bits 8-15, but this is a combination of two
      nibbles (bits 8-11 and bits 12-15) for left and right shifts.
      Due to the incorrect bits extraction, the actual shift may go beyond
      the 32bit value, as spotted recently by UBSAN check:
       UBSAN: Undefined behaviour in sound/pci/ac97/ac97_codec.c:836:7
       shift exponent 68 is too large for 32-bit type 'int'
      
      This patch fixes the shift value extraction by masking the properly
      with 0x0f instead of 0xff.
      Reported-and-tested-by: default avatarMeelis Roos <mroos@linux.ee>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a71ca61f
    • Takashi Iwai's avatar
      ALSA: wss: Fix invalid snd_free_pages() at error path · b307c96b
      Takashi Iwai authored
      commit 7b69154171b407844c273ab4c10b5f0ddcd6aa29 upstream.
      
      Some spurious calls of snd_free_pages() have been overlooked and
      remain in the error paths of wss driver code.  Since runtime->dma_area
      is managed by the PCM core helper, we shouldn't release manually.
      
      Drop the superfluous calls.
      Reviewed-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b307c96b
    • Filipe Manana's avatar
      Btrfs: ensure path name is null terminated at btrfs_control_ioctl · e3fc2151
      Filipe Manana authored
      commit f505754fd6599230371cb01b9332754ddc104be1 upstream.
      
      We were using the path name received from user space without checking that
      it is null terminated. While btrfs-progs is well behaved and does proper
      validation and null termination, someone could call the ioctl and pass
      a non-null terminated patch, leading to buffer overrun problems in the
      kernel.  The ioctl is protected by CAP_SYS_ADMIN.
      
      So just set the last byte of the path to a null character, similar to what
      we do in other ioctls (add/remove/resize device, snapshot creation, etc).
      
      CC: stable@vger.kernel.org # 4.4+
      Reviewed-by: default avatarAnand Jain <anand.jain@oracle.com>
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e3fc2151
    • Max Filippov's avatar
      xtensa: fix coprocessor context offset definitions · 327242a4
      Max Filippov authored
      commit 03bc996af0cc71c7f30c384d8ce7260172423b34 upstream.
      
      Coprocessor context offsets are used by the assembly code that moves
      coprocessor context between the individual fields of the
      thread_info::xtregs_cp structure and coprocessor registers.
      This fixes coprocessor context clobbering on flushing and reloading
      during normal user code execution and user process debugging in the
      presence of more than one coprocessor in the core configuration.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      327242a4
    • Max Filippov's avatar
      xtensa: enable coprocessors that are being flushed · c8e13044
      Max Filippov authored
      commit 2958b66694e018c552be0b60521fec27e8d12988 upstream.
      
      coprocessor_flush_all may be called from a context of a thread that is
      different from the thread being flushed. In that case contents of the
      cpenable special register may not match ti->cpenable of the target
      thread, resulting in unhandled coprocessor exception in the kernel
      context.
      Set cpenable special register to the ti->cpenable of the target register
      for the duration of the flush and restore it afterwards.
      This fixes the following crash caused by coprocessor register inspection
      in native gdb:
      
        (gdb) p/x $w0
        Illegal instruction in kernel: sig: 9 [#1] PREEMPT
        Call Trace:
          ___might_sleep+0x184/0x1a4
          __might_sleep+0x41/0xac
          exit_signals+0x14/0x218
          do_exit+0xc9/0x8b8
          die+0x99/0xa0
          do_illegal_instruction+0x18/0x6c
          common_exception+0x77/0x77
          coprocessor_flush+0x16/0x3c
          arch_ptrace+0x46c/0x674
          sys_ptrace+0x2ce/0x3b4
          system_call+0x54/0x80
          common_exception+0x77/0x77
        note: gdb[100] exited with preempt_count 1
        Killed
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c8e13044
    • Junaid Shahid's avatar
      kvm: mmu: Fix race in emulated page table writes · c931360b
      Junaid Shahid authored
      commit 0e0fee5c539b61fdd098332e0e2cc375d9073706 upstream.
      
      When a guest page table is updated via an emulated write,
      kvm_mmu_pte_write() is called to update the shadow PTE using the just
      written guest PTE value. But if two emulated guest PTE writes happened
      concurrently, it is possible that the guest PTE and the shadow PTE end
      up being out of sync. Emulated writes do not mark the shadow page as
      unsync-ed, so this inconsistency will not be resolved even by a guest TLB
      flush (unless the page was marked as unsync-ed at some other point).
      
      This is fixed by re-reading the current value of the guest PTE after the
      MMU lock has been acquired instead of just using the value that was
      written prior to calling kvm_mmu_pte_write().
      Signed-off-by: default avatarJunaid Shahid <junaids@google.com>
      Reviewed-by: default avatarWanpeng Li <wanpengli@tencent.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c931360b
    • Bernd Eckstein's avatar
      usbnet: ipheth: fix potential recvmsg bug and recvmsg bug 2 · f61ebb6b
      Bernd Eckstein authored
      [ Upstream commit 45611c61dd503454b2edae00aabe1e429ec49ebe ]
      
      The bug is not easily reproducable, as it may occur very infrequently
      (we had machines with 20minutes heavy downloading before it occurred)
      However, on a virual machine (VMWare on Windows 10 host) it occurred
      pretty frequently (1-2 seconds after a speedtest was started)
      
      dev->tx_skb mab be freed via dev_kfree_skb_irq on a callback
      before it is set.
      
      This causes the following problems:
      - double free of the skb or potential memory leak
      - in dmesg: 'recvmsg bug' and 'recvmsg bug 2' and eventually
        general protection fault
      
      Example dmesg output:
      [  134.841986] ------------[ cut here ]------------
      [  134.841987] recvmsg bug: copied 9C24A555 seq 9C24B557 rcvnxt 9C25A6B3 fl 0
      [  134.841993] WARNING: CPU: 7 PID: 2629 at /build/linux-hwe-On9fm7/linux-hwe-4.15.0/net/ipv4/tcp.c:1865 tcp_recvmsg+0x44d/0xab0
      [  134.841994] Modules linked in: ipheth(OE) kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd glue_helper cryptd vmw_balloon intel_rapl_perf joydev input_leds serio_raw vmw_vsock_vmci_transport vsock shpchp i2c_piix4 mac_hid binfmt_misc vmw_vmci parport_pc ppdev lp parport autofs4 vmw_pvscsi vmxnet3 hid_generic usbhid hid vmwgfx ttm drm_kms_helper syscopyarea sysfillrect mptspi mptscsih sysimgblt ahci psmouse fb_sys_fops pata_acpi mptbase libahci e1000 drm scsi_transport_spi
      [  134.842046] CPU: 7 PID: 2629 Comm: python Tainted: G        W  OE    4.15.0-34-generic #37~16.04.1-Ubuntu
      [  134.842046] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017
      [  134.842048] RIP: 0010:tcp_recvmsg+0x44d/0xab0
      [  134.842048] RSP: 0018:ffffa6630422bcc8 EFLAGS: 00010286
      [  134.842049] RAX: 0000000000000000 RBX: ffff997616f4f200 RCX: 0000000000000006
      [  134.842049] RDX: 0000000000000007 RSI: 0000000000000082 RDI: ffff9976257d6490
      [  134.842050] RBP: ffffa6630422bd98 R08: 0000000000000001 R09: 000000000004bba4
      [  134.842050] R10: 0000000001e00c6f R11: 000000000004bba4 R12: ffff99760dee3000
      [  134.842051] R13: 0000000000000000 R14: ffff99760dee3514 R15: 0000000000000000
      [  134.842051] FS:  00007fe332347700(0000) GS:ffff9976257c0000(0000) knlGS:0000000000000000
      [  134.842052] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  134.842053] CR2: 0000000001e41000 CR3: 000000020e9b4006 CR4: 00000000003606e0
      [  134.842055] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  134.842055] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [  134.842057] Call Trace:
      [  134.842060]  ? aa_sk_perm+0x53/0x1a0
      [  134.842064]  inet_recvmsg+0x51/0xc0
      [  134.842066]  sock_recvmsg+0x43/0x50
      [  134.842070]  SYSC_recvfrom+0xe4/0x160
      [  134.842072]  ? __schedule+0x3de/0x8b0
      [  134.842075]  ? ktime_get_ts64+0x4c/0xf0
      [  134.842079]  SyS_recvfrom+0xe/0x10
      [  134.842082]  do_syscall_64+0x73/0x130
      [  134.842086]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
      [  134.842086] RIP: 0033:0x7fe331f5a81d
      [  134.842088] RSP: 002b:00007ffe8da98398 EFLAGS: 00000246 ORIG_RAX: 000000000000002d
      [  134.842090] RAX: ffffffffffffffda RBX: ffffffffffffffff RCX: 00007fe331f5a81d
      [  134.842094] RDX: 00000000000003fb RSI: 0000000001e00874 RDI: 0000000000000003
      [  134.842095] RBP: 00007fe32f642c70 R08: 0000000000000000 R09: 0000000000000000
      [  134.842097] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe332347698
      [  134.842099] R13: 0000000001b7e0a0 R14: 0000000001e00874 R15: 0000000000000000
      [  134.842103] Code: 24 fd ff ff e9 cc fe ff ff 48 89 d8 41 8b 8c 24 10 05 00 00 44 8b 45 80 48 c7 c7 08 bd 59 8b 48 89 85 68 ff ff ff e8 b3 c4 7d ff <0f> 0b 48 8b 85 68 ff ff ff e9 e9 fe ff ff 41 8b 8c 24 10 05 00
      [  134.842126] ---[ end trace b7138fc08c83147f ]---
      [  134.842144] general protection fault: 0000 [#1] SMP PTI
      [  134.842145] Modules linked in: ipheth(OE) kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd glue_helper cryptd vmw_balloon intel_rapl_perf joydev input_leds serio_raw vmw_vsock_vmci_transport vsock shpchp i2c_piix4 mac_hid binfmt_misc vmw_vmci parport_pc ppdev lp parport autofs4 vmw_pvscsi vmxnet3 hid_generic usbhid hid vmwgfx ttm drm_kms_helper syscopyarea sysfillrect mptspi mptscsih sysimgblt ahci psmouse fb_sys_fops pata_acpi mptbase libahci e1000 drm scsi_transport_spi
      [  134.842161] CPU: 7 PID: 2629 Comm: python Tainted: G        W  OE    4.15.0-34-generic #37~16.04.1-Ubuntu
      [  134.842162] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017
      [  134.842164] RIP: 0010:tcp_close+0x2c6/0x440
      [  134.842165] RSP: 0018:ffffa6630422bde8 EFLAGS: 00010202
      [  134.842167] RAX: 0000000000000000 RBX: ffff99760dee3000 RCX: 0000000180400034
      [  134.842168] RDX: 5c4afd407207a6c4 RSI: ffffe868495bd300 RDI: ffff997616f4f200
      [  134.842169] RBP: ffffa6630422be08 R08: 0000000016f4d401 R09: 0000000180400034
      [  134.842169] R10: ffffa6630422bd98 R11: 0000000000000000 R12: 000000000000600c
      [  134.842170] R13: 0000000000000000 R14: ffff99760dee30c8 R15: ffff9975bd44fe00
      [  134.842171] FS:  00007fe332347700(0000) GS:ffff9976257c0000(0000) knlGS:0000000000000000
      [  134.842173] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  134.842174] CR2: 0000000001e41000 CR3: 000000020e9b4006 CR4: 00000000003606e0
      [  134.842177] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  134.842178] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [  134.842179] Call Trace:
      [  134.842181]  inet_release+0x42/0x70
      [  134.842183]  __sock_release+0x42/0xb0
      [  134.842184]  sock_close+0x15/0x20
      [  134.842187]  __fput+0xea/0x220
      [  134.842189]  ____fput+0xe/0x10
      [  134.842191]  task_work_run+0x8a/0xb0
      [  134.842193]  exit_to_usermode_loop+0xc4/0xd0
      [  134.842195]  do_syscall_64+0xf4/0x130
      [  134.842197]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
      [  134.842197] RIP: 0033:0x7fe331f5a560
      [  134.842198] RSP: 002b:00007ffe8da982e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000003
      [  134.842200] RAX: 0000000000000000 RBX: 00007fe32f642c70 RCX: 00007fe331f5a560
      [  134.842201] RDX: 00000000008f5320 RSI: 0000000001cd4b50 RDI: 0000000000000003
      [  134.842202] RBP: 00007fe32f6500f8 R08: 000000000000003c R09: 00000000009343c0
      [  134.842203] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe32f6500d0
      [  134.842204] R13: 00000000008f5320 R14: 00000000008f5320 R15: 0000000001cd4770
      [  134.842205] Code: c8 00 00 00 45 31 e4 49 39 fe 75 4d eb 50 83 ab d8 00 00 00 01 48 8b 17 48 8b 47 08 48 c7 07 00 00 00 00 48 c7 47 08 00 00 00 00 <48> 89 42 08 48 89 10 0f b6 57 34 8b 47 2c 2b 47 28 83 e2 01 80
      [  134.842226] RIP: tcp_close+0x2c6/0x440 RSP: ffffa6630422bde8
      [  134.842227] ---[ end trace b7138fc08c831480 ]---
      
      The proposed patch eliminates a potential racing condition.
      Before, usb_submit_urb was called and _after_ that, the skb was attached
      (dev->tx_skb). So, on a callback it was possible, however unlikely that the
      skb was freed before it was set. That way (because dev->tx_skb was not set
      to NULL after it was freed), it could happen that a skb from a earlier
      transmission was freed a second time (and the skb we should have freed did
      not get freed at all)
      
      Now we free the skb directly in ipheth_tx(). It is not passed to the
      callback anymore, eliminating the posibility of a double free of the same
      skb. Depending on the retval of usb_submit_urb() we use dev_kfree_skb_any()
      respectively dev_consume_skb_any() to free the skb.
      Signed-off-by: default avatarOliver Zweigle <Oliver.Zweigle@faro.com>
      Signed-off-by: default avatarBernd Eckstein <3ernd.Eckstein@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f61ebb6b
    • Julian Wiedmann's avatar
      s390/qeth: fix length check in SNMP processing · 6ae0dc6c
      Julian Wiedmann authored
      [ Upstream commit 9a764c1e59684c0358e16ccaafd870629f2cfe67 ]
      
      The response for a SNMP request can consist of multiple parts, which
      the cmd callback stages into a kernel buffer until all parts have been
      received. If the callback detects that the staging buffer provides
      insufficient space, it bails out with error.
      This processing is buggy for the first part of the response - while it
      initially checks for a length of 'data_len', it later copies an
      additional amount of 'offsetof(struct qeth_snmp_cmd, data)' bytes.
      
      Fix the calculation of 'data_len' for the first part of the response.
      This also nicely cleans up the memcpy code.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarJulian Wiedmann <jwi@linux.ibm.com>
      Reviewed-by: default avatarUrsula Braun <ubraun@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6ae0dc6c
    • Pan Bian's avatar
      rapidio/rionet: do not free skb before reading its length · 9ab8f8cb
      Pan Bian authored
      [ Upstream commit cfc435198f53a6fa1f656d98466b24967ff457d0 ]
      
      skb is freed via dev_kfree_skb_any, however, skb->len is read then. This
      may result in a use-after-free bug.
      
      Fixes: e6161d64 ("rapidio/rionet: rework driver initialization and removal")
      Signed-off-by: default avatarPan Bian <bianpan2016@163.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9ab8f8cb
    • Sasha Levin's avatar
      Revert "wlcore: Add missing PM call for wlcore_cmd_wait_for_event_or_timeout()" · 494fedde
      Sasha Levin authored
      This reverts commit 3fdd3464 which was
      upstream commit 4ec7cece87b3ed21ffcd407c62fb2f151a366bc1.
      
      From Dietmar May's report on the stable mailing list
      (https://www.spinics.net/lists/stable/msg272201.html):
      
      > I've run into some problems which appear due to (a) recent patch(es) on
      > the wlcore wifi driver.
      >
      > 4.4.160 - commit 3fdd3464
      > 4.9.131 - commit afeeecc7
      >
      > Earlier versions (4.9.130 and 4.4.159 - tested back to 4.4.49) do not
      > exhibit this problem. It is still present in 4.9.141.
      >
      > master as of 4.20.0-rc4 does not exhibit this problem.
      >
      > Basically, during client association when in AP mode (running hostapd),
      > handshake may or may not complete following a noticeable delay. If
      > successful, then the driver fails consistently in warn_slowpath_null
      > during disassociation. If unsuccessful, the wifi client attempts multiple
      > times, sometimes failing repeatedly. I've had clients unable to connect
      > for 3-5 minutes during testing, with the syslog filled with dozens of
      > backtraces. syslog details are below.
      >
      > I'm working on an embedded device with a TI 3352 ARM processor and a
      > murata wl1271 module in sdio mode. We're running a fully patched ubuntu
      > 18.04 ARM build, with a kernel built from kernel.org's stable/linux repo <https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-4.9.y&id=afeeecc764436f31d4447575bb9007732333818c>.
      > Relevant parts of the kernel config are included below.
      >
      > The commit message states:
      >
      > > /I've only seen this few times with the runtime PM patches enabled so
      > > this one is probably not needed before that. This seems to work
      > > currently based on the current PM implementation timer. Let's apply
      > > this separately though in case others are hitting this issue./
      > We're not doing anything explicit with power management. The device is an
      > IoT edge gateway with battery backup, normally running on wall power. The
      > battery is currently used solely to shut down the system cleanly to avoid
      > filesystem corruption.
      >
      > The device tree is configured to keep power in suspend; but the device
      > should never suspend, so in our case, there is no need to call
      > wl1271_ps_elp_wakeup() or wl1271_ps_elp_sleep(), as occurs in the patch.
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      494fedde
    • Matthias Schwarzott's avatar
      media: em28xx: Fix use-after-free when disconnecting · 4de120cb
      Matthias Schwarzott authored
      [ Upstream commit 910b0797 ]
      
      Fix bug by moving the i2c_unregister_device calls after deregistration
      of dvb frontend.
      
      The new style i2c drivers already destroys the frontend object at
      i2c_unregister_device time.
      When the dvb frontend is unregistered afterwards it leads to this oops:
      
        [ 6058.866459] BUG: unable to handle kernel NULL pointer dereference at 00000000000001f8
        [ 6058.866578] IP: dvb_frontend_stop+0x30/0xd0 [dvb_core]
        [ 6058.866644] PGD 0
        [ 6058.866646] P4D 0
      
        [ 6058.866726] Oops: 0000 [#1] SMP
        [ 6058.866768] Modules linked in: rc_pinnacle_pctv_hd(O) em28xx_rc(O) si2157(O) si2168(O) em28xx_dvb(O) em28xx(O) si2165(O) a8293(O) tda10071(O) tea5767(O) tuner(O) cx23885(O) tda18271(O) videobuf2_dvb(O) videobuf2_dma_sg(O) m88ds3103(O) tveeprom(O) cx2341x(O) v4l2_common(O) dvb_core(O) rc_core(O) videobuf2_memops(O) videobuf2_v4l2(O) videobuf2_core(O) videodev(O) media(O) bluetooth ecdh_generic ums_realtek uas rtl8192cu rtl_usb rtl8192c_common rtlwifi usb_storage snd_hda_codec_realtek snd_hda_codec_hdmi snd_hda_codec_generic i2c_mux snd_hda_intel snd_hda_codec snd_hwdep x86_pkg_temp_thermal snd_hda_core kvm_intel kvm irqbypass [last unloaded: videobuf2_memops]
        [ 6058.867497] CPU: 2 PID: 7349 Comm: kworker/2:0 Tainted: G        W  O    4.13.9-gentoo #1
        [ 6058.867595] Hardware name: MEDION E2050 2391/H81H3-EM2, BIOS H81EM2W08.308 08/25/2014
        [ 6058.867692] Workqueue: usb_hub_wq hub_event
        [ 6058.867746] task: ffff88011a15e040 task.stack: ffffc90003074000
        [ 6058.867825] RIP: 0010:dvb_frontend_stop+0x30/0xd0 [dvb_core]
        [ 6058.867896] RSP: 0018:ffffc90003077b58 EFLAGS: 00010293
        [ 6058.867964] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000010040001f
        [ 6058.868056] RDX: ffff88011a15e040 RSI: ffffea000464e400 RDI: ffff88001cbe3028
        [ 6058.868150] RBP: ffffc90003077b68 R08: ffff880119390380 R09: 000000010040001f
        [ 6058.868241] R10: ffffc90003077b18 R11: 000000000001e200 R12: ffff88001cbe3028
        [ 6058.868330] R13: ffff88001cbe68d0 R14: ffff8800cf734000 R15: ffff8800cf734098
        [ 6058.868419] FS:  0000000000000000(0000) GS:ffff88011fb00000(0000) knlGS:0000000000000000
        [ 6058.868511] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        [ 6058.868578] CR2: 00000000000001f8 CR3: 00000001113c5000 CR4: 00000000001406e0
        [ 6058.868662] Call Trace:
        [ 6058.868705]  dvb_unregister_frontend+0x2a/0x80 [dvb_core]
        [ 6058.868774]  em28xx_dvb_fini+0x132/0x220 [em28xx_dvb]
        [ 6058.868840]  em28xx_close_extension+0x34/0x90 [em28xx]
        [ 6058.868902]  em28xx_usb_disconnect+0x4e/0x70 [em28xx]
        [ 6058.868968]  usb_unbind_interface+0x6d/0x260
        [ 6058.869025]  device_release_driver_internal+0x150/0x210
        [ 6058.869094]  device_release_driver+0xd/0x10
        [ 6058.869150]  bus_remove_device+0xe4/0x160
        [ 6058.869204]  device_del+0x1ce/0x2f0
        [ 6058.869253]  usb_disable_device+0x99/0x270
        [ 6058.869306]  usb_disconnect+0x8d/0x260
        [ 6058.869359]  hub_event+0x93d/0x1520
        [ 6058.869408]  ? dequeue_task_fair+0xae5/0xd20
        [ 6058.869467]  process_one_work+0x1d9/0x3e0
        [ 6058.869522]  worker_thread+0x43/0x3e0
        [ 6058.869576]  kthread+0x104/0x140
        [ 6058.869602]  ? trace_event_raw_event_workqueue_work+0x80/0x80
        [ 6058.869640]  ? kthread_create_on_node+0x40/0x40
        [ 6058.869673]  ret_from_fork+0x22/0x30
        [ 6058.869698] Code: 54 49 89 fc 53 48 8b 9f 18 03 00 00 0f 1f 44 00 00 41 83 bc 24 04 05 00 00 02 74 0c 41 c7 84 24 04 05 00 00 01 00 00 00 0f ae f0 <48> 8b bb f8 01 00 00 48 85 ff 74 5c e8 df 40 f0 e0 48 8b 93 f8
        [ 6058.869850] RIP: dvb_frontend_stop+0x30/0xd0 [dvb_core] RSP: ffffc90003077b58
        [ 6058.869894] CR2: 00000000000001f8
        [ 6058.875880] ---[ end trace 717eecf7193b3fc6 ]---
      Signed-off-by: default avatarMatthias Schwarzott <zzam@gentoo.org>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4de120cb
  2. 01 Dec, 2018 15 commits