1. 11 Jun, 2019 40 commits
    • Daniel Axtens's avatar
      net: create skb_gso_validate_mac_len() · a33b6d4c
      Daniel Axtens authored
      commit 2b16f048
      If you take a GSO skb, and split it into packets, will the MAC
      length (L2 + L3 + L4 headers + payload) of those packets be small
      enough to fit within a given length?
      Move skb_gso_mac_seglen() to skbuff.h with other related functions
      like skb_gso_network_seglen() so we can use it, and then create
      skb_gso_validate_mac_len to do the full calculation.
      Signed-off-by: default avatarDaniel Axtens <dja@axtens.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 4.4: There is no GSO_BY_FRAGS case to handle, so
       skb_gso_validate_mac_len() becomes a trivial comparison. Put it inline in
      Signed-off-by: default avatarBen Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Todd Kjos's avatar
      binder: replace "%p" with "%pK" · c53c1a82
      Todd Kjos authored
      commit 8ca86f16
      The format specifier "%p" can leak kernel addresses. Use
      "%pK" instead. There were 4 remaining cases in binder.c.
      Signed-off-by: default avatarTodd Kjos <tkjos@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      [bwh: Backported to 4.4: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Ben Hutchings's avatar
      binder: Replace "%p" with "%pK" for stable · 5280efe4
      Ben Hutchings authored
      This was done as part of upstream commits fdfb4a99 "8inder:
      separate binder allocator structure from binder proc", 19c98724
      "binder: separate out binder_alloc functions", and 7a4408c6
      "binder: make sure accesses to proc/thread are safe".  However, those
      commits made lots of other changes that are not suitable for stable.
      Signed-off-by: default avatarBen Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Roberto Bergantinos Corpas's avatar
      CIFS: cifs_read_allocate_pages: don't iterate through whole page array on ENOMEM · 336c1662
      Roberto Bergantinos Corpas authored
      commit 31fad7d41e73731f05b8053d17078638cf850fa6 upstream.
       In cifs_read_allocate_pages, in case of ENOMEM, we go through
      whole rdata->pages array but we have failed the allocation before
      nr_pages, therefore we may end up calling put_page with NULL
      pointer, causing oops
      Signed-off-by: default avatarRoberto Bergantinos Corpas <rbergant@redhat.com>
      Acked-by: default avatarPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Zhenliang Wei's avatar
      kernel/signal.c: trace_signal_deliver when signal_group_exit · 360f8fe4
      Zhenliang Wei authored
      commit 98af37d624ed8c83f1953b1b6b2f6866011fc064 upstream.
      In the fixes commit, removing SIGKILL from each thread signal mask and
      executing "goto fatal" directly will skip the call to
      "trace_signal_deliver".  At this point, the delivery tracking of the
      SIGKILL signal will be inaccurate.
      Therefore, we need to add trace_signal_deliver before "goto fatal" after
      executing sigdelset.
      Note: SEND_SIG_NOINFO matches the fact that SIGKILL doesn't have any info.
      Link: http://lkml.kernel.org/r/20190425025812.91424-1-weizhenliang@huawei.com
      Fixes: cf43a757fd4944 ("signal: Restore the stop PTRACE_EVENT_EXIT")
      Signed-off-by: default avatarZhenliang Wei <weizhenliang@huawei.com>
      Reviewed-by: default avatarChristian Brauner <christian@brauner.io>
      Reviewed-by: default avatarOleg Nesterov <oleg@redhat.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Ivan Delalande <colona@arista.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Deepa Dinamani <deepa.kernel@gmail.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: <stable@vger.kernel.org>
      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>
    • Jiri Slaby's avatar
      memcg: make it work on sparse non-0-node systems · 7a47d187
      Jiri Slaby authored
      commit 3e8589963773a5c23e2f1fe4bcad0e9a90b7f471 upstream.
      We have a single node system with node 0 disabled:
        Scanning NUMA topology in Northbridge 24
        Number of physical nodes 2
        Skipping disabled node 0
        Node 1 MemBase 0000000000000000 Limit 00000000fbff0000
        NODE_DATA(1) allocated [mem 0xfbfda000-0xfbfeffff]
      This causes crashes in memcg when system boots:
        BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
        #PF error: [normal kernel read fault]
        RIP: 0010:list_lru_add+0x94/0x170
        Call Trace:
      It is reproducible as far as 4.12.  I did not try older kernels.  You have
      to have a new enough systemd, e.g.  241 (the reason is unknown -- was not
      investigated).  Cannot be reproduced with systemd 234.
      The system crashes because the size of lru array is never updated in
      memcg_update_all_list_lrus and the reads are past the zero-sized array,
      causing dereferences of random memory.
      The root cause are list_lru_memcg_aware checks in the list_lru code.  The
      test in list_lru_memcg_aware is broken: it assumes node 0 is always
      present, but it is not true on some systems as can be seen above.
      So fix this by avoiding checks on node 0.  Remember the memcg-awareness by
      a bool flag in struct list_lru.
      Link: http://lkml.kernel.org/r/20190522091940.3615-1-jslaby@suse.cz
      Fixes: 60d3fd32
       ("list_lru: introduce per-memcg lists")
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Suggested-by: default avatarVladimir Davydov <vdavydov.dev@gmail.com>
      Acked-by: default avatarVladimir Davydov <vdavydov.dev@gmail.com>
      Reviewed-by: default avatarShakeel Butt <shakeelb@google.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
      Cc: <stable@vger.kernel.org>
      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>
    • Joe Burmeister's avatar
      tty: max310x: Fix external crystal register setup · 5db0a9c3
      Joe Burmeister authored
      commit 5d24f455c182d5116dd5db8e1dc501115ecc9c2c upstream.
      The datasheet states:
        Bit 4: ClockEnSet the ClockEn bit high to enable an external clocking
      (crystal or clock generator at XIN). Set the ClockEn bit to 0 to disable
        Bit 1: CrystalEnSet the CrystalEn bit high to enable the crystal
      oscillator. When using an external clock source at XIN, CrystalEn must
      be set low.
      The bit 4, MAX310X_CLKSRC_EXTCLK_BIT, should be set and was not.
      This was required to make the MAX3107 with an external crystal on our
      board able to send or receive data.
      Signed-off-by: default avatarJoe Burmeister <joe.burmeister@devtank.co.uk>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Jorge Ramirez-Ortiz's avatar
      tty: serial: msm_serial: Fix XON/XOFF · e4987453
      Jorge Ramirez-Ortiz authored
      commit 61c0e37950b88bad590056286c1d766b1f167f4e upstream.
      When the tty layer requests the uart to throttle, the current code
      executing in msm_serial will trigger "Bad mode in Error Handler" and
      generate an invalid stack frame in pstore before rebooting (that is if
      pstore is indeed configured: otherwise the user shall just notice a
      reboot with no further information dumped to the console).
      This patch replaces the PIO byte accessor with the word accessor
      already used in PIO mode.
      Fixes: 68252424
       ("tty: serial: msm: Support big-endian CPUs")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
      Reviewed-by: default avatarBjorn Andersson <bjorn.andersson@linaro.org>
      Reviewed-by: default avatarStephen Boyd <swboyd@chromium.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Lyude Paul's avatar
      drm/nouveau/i2c: Disable i2c bus access after ->fini() · 986adddb
      Lyude Paul authored
      commit 342406e4fbba9a174125fbfe6aeac3d64ef90f76 upstream.
      For a while, we've had the problem of i2c bus access not grabbing
      a runtime PM ref when it's being used in userspace by i2c-dev, resulting
      in nouveau spamming the kernel log with errors if anything attempts to
      access the i2c bus while the GPU is in runtime suspend. An example:
      [  130.078386] nouveau 0000:01:00.0: i2c: aux 000d: begin idle timeout ffffffff
      Since the GPU is in runtime suspend, the MMIO region that the i2c bus is
      on isn't accessible. On x86, the standard behavior for accessing an
      unavailable MMIO region is to just return ~0.
      Except, that turned out to be a lie. While computers with a clean
      concious will return ~0 in this scenario, some machines will actually
      completely hang a CPU on certian bad MMIO accesses. This was witnessed
      with someone's Lenovo ThinkPad P50, where sensors-detect attempting to
      access the i2c bus while the GPU was suspended would result in a CPU
        CPU: 5 PID: 12438 Comm: sensors-detect Not tainted 5.0.0-0.rc4.git3.1.fc30.x86_64 #1
        Hardware name: LENOVO 20EQS64N17/20EQS64N17, BIOS N1EET74W (1.47 ) 11/21/2017
        RIP: 0010:ioread32+0x2b/0x30
        Code: 81 ff ff ff 03 00 77 20 48 81 ff 00 00 01 00 76 05 0f b7 d7 ed c3
        48 c7 c6 e1 0c 36 96 e8 2d ff ff ff b8 ff ff ff ff c3 8b 07 <c3> 0f 1f
        40 00 49 89 f0 48 81 fe ff ff 03 00 76 04 40 88 3e c3 48
        RSP: 0018:ffffaac3c5007b48 EFLAGS: 00000292 ORIG_RAX: ffffffffffffff13
        RAX: 0000000001111000 RBX: 0000000001111000 RCX: 0000043017a97186
        RDX: 0000000000000aaa RSI: 0000000000000005 RDI: ffffaac3c400e4e4
        RBP: ffff9e6443902c00 R08: ffffaac3c400e4e4 R09: ffffaac3c5007be7
        R10: 0000000000000004 R11: 0000000000000001 R12: ffff9e6445dd0000
        R13: 000000000000e4e4 R14: 00000000000003c4 R15: 0000000000000000
        FS:  00007f253155a740(0000) GS:ffff9e644f600000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 00005630d1500358 CR3: 0000000417c44006 CR4: 00000000003606e0
        DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
        DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
        Call Trace:
         g94_i2c_aux_xfer+0x326/0x850 [nouveau]
         nvkm_i2c_aux_i2c_xfer+0x9e/0x140 [nouveau]
         ? _raw_spin_unlock_irqrestore+0x1/0x60
         ? rt_mutex_slowlock.constprop.0+0x13d/0x1e0
         ? __lock_is_held+0x59/0xa0
         i2cdev_ioctl_smbus+0x162/0x2d0 [i2c_dev]
         i2cdev_ioctl+0x1db/0x2c0 [i2c_dev]
        RIP: 0033:0x7f25317f546b
        Code: 0f 1e fa 48 8b 05 1d da 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff
        ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01
        f0 ff ff 73 01 c3 48 8b 0d ed d9 0c 00 f7 d8 64 89 01 48
        RSP: 002b:00007ffc88caab68 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
        RAX: ffffffffffffffda RBX: 00005630d0fe7260 RCX: 00007f25317f546b
        RDX: 00005630d1598e80 RSI: 0000000000000720 RDI: 0000000000000003
        RBP: 00005630d155b968 R08: 0000000000000001 R09: 00005630d15a1da0
        R10: 0000000000000070 R11: 0000000000000246 R12: 00005630d1598e80
        R13: 00005630d12f3d28 R14: 0000000000000720 R15: 00005630d12f3ce0
        watchdog: BUG: soft lockup - CPU#5 stuck for 23s! [sensors-detect:12438]
      Yikes! While I wanted to try to make it so that accessing an i2c bus on
      nouveau would wake up the GPU as needed, airlied pointed out that pretty
      much any usecase for userspace accessing an i2c bus on a GPU (mainly for
      the DDC brightness control that some displays have) is going to only be
      useful while there's at least one display enabled on the GPU anyway, and
      the GPU never sleeps while there's displays running.
      Since teaching the i2c bus to wake up the GPU on userspace accesses is a
      good deal more difficult than it might seem, mostly due to the fact that
      we have to use the i2c bus during runtime resume of the GPU, we instead
      opt for the easiest solution: don't let userspace access i2c busses on
      the GPU at all while it's in runtime suspend.
      Changes since v1:
      * Also disable i2c busses that run over DP AUX
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Kailang Yang's avatar
      ALSA: hda/realtek - Set default power save node to 0 · bf8f6b43
      Kailang Yang authored
      commit 317d9313925cd8388304286c0d3c8dda7f060a2d upstream.
      I measured power consumption between power_save_node=1 and power_save_node=0.
      It's almost the same.
      Codec will enter to runtime suspend and suspend.
      That pin also will enter to D3. Don't need to enter to D3 by single pin.
      So, Disable power_save_node as default. It will avoid more issues.
      Windows Driver also has not this option at runtime PM.
      Signed-off-by: default avatarKailang Yang <kailang@realtek.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>
    • Filipe Manana's avatar
      Btrfs: fix race updating log root item during fsync · 494447b9
      Filipe Manana authored
      commit 06989c799f04810f6876900d4760c0edda369cf7 upstream.
      When syncing the log, the final phase of a fsync operation, we need to
      either create a log root's item or update the existing item in the log
      tree of log roots, and that depends on the current value of the log
      root's log_transid - if it's 1 we need to create the log root item,
      otherwise it must exist already and we update it. Since there is no
      synchronization between updating the log_transid and checking it for
      deciding whether the log root's item needs to be created or updated, we
      end up with a tiny race window that results in attempts to update the
      item to fail because the item was not yet created:
                    CPU 1                                    CPU 2
          lock root->log_mutex
          set log root's log_transid to 1
          unlock root->log_mutex
                                                       lock root->log_mutex
                                                       sets log root's
                                                       log_transid to 2
                                                       unlock root->log_mutex
            sees log root's log_transid
            with a value of 2
              calls btrfs_update_root(),
              which fails with -EUCLEAN
              and causes transaction abort
      Until recently the race lead to a BUG_ON at btrfs_update_root(), but after
      the recent commit 7ac1e464c4d47 ("btrfs: Don't panic when we can't find a
      root key") we just abort the current transaction.
      A sample trace of the BUG_ON() on a SLE12 kernel:
        ------------[ cut here ]------------
        kernel BUG at ../fs/btrfs/root-tree.c:157!
        Oops: Exception in kernel mode, sig: 5 [#1]
        SMP NR_CPUS=2048 NUMA pSeries
        Supported: Yes, External
        CPU: 78 PID: 76303 Comm: rtas_errd Tainted: G                 X 4.4.156-94.57-default #1
        task: c00000ffa906d010 ti: c00000ff42b08000 task.ti: c00000ff42b08000
        NIP: d000000036ae5cdc LR: d000000036ae5cd8 CTR: 0000000000000000
        REGS: c00000ff42b0b860 TRAP: 0700   Tainted: G                 X  (4.4.156-94.57-default)
        MSR: 8000000002029033 <SF,VEC,EE,ME,IR,DR,RI,LE>  CR: 22444484  XER: 20000000
        CFAR: d000000036aba66c SOFTE: 1
        GPR00: d000000036ae5cd8 c00000ff42b0bae0 d000000036bda220 0000000000000054
        GPR04: 0000000000000001 0000000000000000 c00007ffff8d37c8 0000000000000000
        GPR08: c000000000e19c00 0000000000000000 0000000000000000 3736343438312079
        GPR12: 3930373337303434 c000000007a3a800 00000000007fffff 0000000000000023
        GPR16: c00000ffa9d26028 c00000ffa9d261f8 0000000000000010 c00000ffa9d2ab28
        GPR20: c00000ff42b0bc48 0000000000000001 c00000ff9f0d9888 0000000000000001
        GPR24: c00000ffa9d26000 c00000ffa9d261e8 c00000ffa9d2a800 c00000ff9f0d9888
        GPR28: c00000ffa9d26028 c00000ffa9d2aa98 0000000000000001 c00000ffa98f5b20
        NIP [d000000036ae5cdc] btrfs_update_root+0x25c/0x4e0 [btrfs]
        LR [d000000036ae5cd8] btrfs_update_root+0x258/0x4e0 [btrfs]
        Call Trace:
        [c00000ff42b0bae0] [d000000036ae5cd8] btrfs_update_root+0x258/0x4e0 [btrfs] (unreliable)
        [c00000ff42b0bba0] [d000000036b53610] btrfs_sync_log+0x2d0/0xc60 [btrfs]
        [c00000ff42b0bce0] [d000000036b1785c] btrfs_sync_file+0x44c/0x4e0 [btrfs]
        [c00000ff42b0bd80] [c00000000032e300] vfs_fsync_range+0x70/0x120
        [c00000ff42b0bdd0] [c00000000032e44c] do_fsync+0x5c/0xb0
        [c00000ff42b0be10] [c00000000032e8dc] SyS_fdatasync+0x2c/0x40
        [c00000ff42b0be30] [c000000000009488] system_call+0x3c/0x100
        Instruction dump:
        7f43d378 4bffebb9 60000000 88d90008 3d220000 e8b90000 3b390009 e87a01f0
        e8898e08 e8f90000 4bfd48e5 60000000 <0fe00000> e95b0060 39200004 394a0ea0
        ---[ end trace 8f2dc8f919cabab8 ]---
      So fix this by doing the check of log_transid and updating or creating the
      log root's item while holding the root's log_mutex.
      Fixes: 7237f183
       ("Btrfs: fix tree logs parallel sync")
      CC: stable@vger.kernel.org # 4.4+
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Steffen Maier's avatar
      scsi: zfcp: fix to prevent port_remove with pure auto scan LUNs (only sdevs) · af34de02
      Steffen Maier authored
      commit ef4021fe5fd77ced0323cede27979d80a56211ca upstream.
      When the user tries to remove a zfcp port via sysfs, we only rejected it if
      there are zfcp unit children under the port. With purely automatically
      scanned LUNs there are no zfcp units but only SCSI devices. In such cases,
      the port_remove erroneously continued. We close the port and this
      implicitly closes all LUNs under the port. The SCSI devices survive with
      their private zfcp_scsi_dev still holding a reference to the "removed"
      zfcp_port (still allocated but invisible in sysfs) [zfcp_get_port_by_wwpn
      in zfcp_scsi_slave_alloc]. This is not a problem as long as the fc_rport
      stays blocked. Once (auto) port scan brings back the removed port, we
      unblock its fc_rport again by design.  However, there is no mechanism that
      would recover (open) the LUNs under the port (no "ersfs_3" without
      zfcp_unit [zfcp_erp_strategy_followup_success]).  Any pending or new I/O to
      such LUN leads to repeated:
        Done: NEEDS_RETRY Result: hostbyte=DID_IMM_RETRY driverbyte=DRIVER_OK
      See also v4.10 commit 6f2ce1c6 ("scsi: zfcp: fix rport unblock race
      with LUN recovery"). Even a manual LUN recovery
      (echo 0 > /sys/bus/scsi/devices/H:C:T:L/zfcp_failed)
      does not help, as the LUN links to the old "removed" port which remains
      to lack ZFCP_STATUS_COMMON_RUNNING [zfcp_erp_required_act].
      The only workaround is to first ensure that the fc_rport is blocked
      (e.g. port_remove again in case it was re-discovered by (auto) port scan),
      then delete the SCSI devices, and finally re-discover by (auto) port scan.
      The port scan includes an fc_rport unblock, which in turn triggers
      a new scan on the scsi target to freshly get new pure auto scan LUNs.
      Fix this by rejecting port_remove also if there are SCSI devices
      (even without any zfcp_unit) under this port. Re-use mechanics from v3.7
      commit d99b601b
       ("[SCSI] zfcp: restore refcount check on port_remove").
      However, we have to give up zfcp_sysfs_port_units_mutex earlier in unit_add
      to prevent a deadlock with scsi_host scan taking shost->scan_mutex first
      and then zfcp_sysfs_port_units_mutex now in our zfcp_scsi_slave_alloc().
      Signed-off-by: default avatarSteffen Maier <maier@linux.ibm.com>
      Fixes: b62a8d9b ("[SCSI] zfcp: Use SCSI device data zfcp scsi dev instead of zfcp unit")
      Fixes: f8210e34
       ("[SCSI] zfcp: Allow midlayer to scan for LUNs when running in NPIV mode")
      Cc: <stable@vger.kernel.org> #2.6.37+
      Reviewed-by: default avatarBenjamin Block <bblock@linux.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Steffen Maier's avatar
      scsi: zfcp: fix missing zfcp_port reference put on -EBUSY from port_remove · e85d0025
      Steffen Maier authored
      commit d27e5e07f9c49bf2a6a4ef254ce531c1b4fb5a38 upstream.
      With this early return due to zfcp_unit child(ren), we don't use the
      zfcp_port reference from the earlier zfcp_get_port_by_wwpn() anymore and
      need to put it.
      Signed-off-by: default avatarSteffen Maier <maier@linux.ibm.com>
      Fixes: d99b601b
       ("[SCSI] zfcp: restore refcount check on port_remove")
      Cc: <stable@vger.kernel.org> #3.7+
      Reviewed-by: default avatarJens Remus <jremus@linux.ibm.com>
      Reviewed-by: default avatarBenjamin Block <bblock@linux.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Mauro Carvalho Chehab's avatar
      media: smsusb: better handle optional alignment · 8282730a
      Mauro Carvalho Chehab authored
      commit a47686636d84eaec5c9c6e84bd5f96bed34d526d upstream.
      Most Siano devices require an alignment for the response.
      Changeset f3be52b0056a ("media: usb: siano: Fix general protection fault in smsusb")
      changed the logic with gets such aligment, but it now produces a
      sparce warning:
      drivers/media/usb/siano/smsusb.c: In function 'smsusb_init_device':
      drivers/media/usb/siano/smsusb.c:447:37: warning: 'in_maxp' may be used uninitialized in this function [-Wmaybe-uninitialized]
        447 |   dev->response_alignment = in_maxp - sizeof(struct sms_msg_hdr);
            |                             ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
      The sparse message itself is bogus, but a broken (or fake) USB
      eeprom could produce a negative value for response_alignment.
      So, change the code in order to check if the result is not
      Fixes: 31e0456de5be ("media: usb: siano: Fix general protection fault in smsusb")
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Alan Stern's avatar
      media: usb: siano: Fix false-positive "uninitialized variable" warning · 0bce1ea8
      Alan Stern authored
      commit 45457c01171fd1488a7000d1751c06ed8560ee38 upstream.
      GCC complains about an apparently uninitialized variable recently
      added to smsusb_init_device().  It's a false positive, but to silence
      the warning this patch adds a trivial initialization.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-by: default avatarkbuild test robot <lkp@intel.com>
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Alan Stern's avatar
      media: usb: siano: Fix general protection fault in smsusb · b1782be7
      Alan Stern authored
      commit 31e0456de5be379b10fea0fa94a681057114a96e upstream.
      The syzkaller USB fuzzer found a general-protection-fault bug in the
      smsusb part of the Siano DVB driver.  The fault occurs during probe
      because the driver assumes without checking that the device has both
      IN and OUT endpoints and the IN endpoint is ep1.
      By slightly rearranging the driver's initialization code, we can make
      the appropriate checks early on and thus avoid the problem.  If the
      expected endpoints aren't present, the new code safely returns -ENODEV
      from the probe routine.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-and-tested-by: syzbot+53f029db71c19a47325a@syzkaller.appspotmail.com
      CC: <stable@vger.kernel.org>
      Reviewed-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Oliver Neukum's avatar
      USB: rio500: fix memory leak in close after disconnect · d52c0ffb
      Oliver Neukum authored
      commit e0feb73428b69322dd5caae90b0207de369b5575 upstream.
      If a disconnected device is closed, rio_close() must free
      the buffers.
      Signed-off-by: default avatarOliver Neukum <oneukum@suse.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Oliver Neukum's avatar
      USB: rio500: refuse more than one device at a time · b92be99a
      Oliver Neukum authored
      commit 3864d33943b4a76c6e64616280e98d2410b1190f upstream.
      This driver is using a global variable. It cannot handle more than
      one device at a time. The issue has been existing since the dawn
      of the driver.
      Signed-off-by: default avatarOliver Neukum <oneukum@suse.com>
      Reported-by: syzbot+35f04d136fc975a70da4@syzkaller.appspotmail.com
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Maximilian Luz's avatar
      USB: Add LPM quirk for Surface Dock GigE adapter · ee9d750e
      Maximilian Luz authored
      commit ea261113385ac0a71c2838185f39e8452d54b152 upstream.
      Without USB_QUIRK_NO_LPM ethernet will not work and rtl8152 will
      complain with
          r8152 <device...>: Stop submitting intr, status -71
      Adding the quirk resolves this. As the dock is externally powered, this
      should not have any drawbacks.
      Signed-off-by: default avatarMaximilian Luz <luzmaximilian@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Oliver Neukum's avatar
      USB: sisusbvga: fix oops in error path of sisusb_probe · 30e66d7d
      Oliver Neukum authored
      commit 9a5729f68d3a82786aea110b1bfe610be318f80a upstream.
      The pointer used to log a failure of usb_register_dev() must
      be set before the error is logged.
      v2: fix that minor is not available before registration
      Signed-off-by: default avataroliver Neukum <oneukum@suse.com>
      Reported-by: syzbot+a0cbdbd6d169020c8959@syzkaller.appspotmail.com
      Fixes: 7b5cd5fe
       ("USB: SisUSB2VGA: Convert printk to dev_* macros")
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Alan Stern's avatar
      USB: Fix slab-out-of-bounds write in usb_get_bos_descriptor · 018b7ea9
      Alan Stern authored
      commit a03ff54460817c76105f81f3aa8ef655759ccc9a upstream.
      The syzkaller USB fuzzer found a slab-out-of-bounds write bug in the
      USB core, caused by a failure to check the actual size of a BOS
      descriptor.  This patch adds a check to make sure the descriptor is at
      least as large as it is supposed to be, so that the code doesn't
      inadvertently access memory beyond the end of the allocated region
      when assigning to dev->bos->desc->bNumDeviceCaps later on.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-and-tested-by: syzbot+71f1e64501a309fcc012@syzkaller.appspotmail.com
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Carsten Schmid's avatar
      usb: xhci: avoid null pointer deref when bos field is NULL · f5e1ec93
      Carsten Schmid authored
      commit 7aa1bb2ffd84d6b9b5f546b079bb15cd0ab6e76e upstream.
      With defective USB sticks we see the following error happen:
      usb 1-3: new high-speed USB device number 6 using xhci_hcd
      usb 1-3: device descriptor read/64, error -71
      usb 1-3: device descriptor read/64, error -71
      usb 1-3: new high-speed USB device number 7 using xhci_hcd
      usb 1-3: device descriptor read/64, error -71
      usb 1-3: unable to get BOS descriptor set
      usb 1-3: New USB device found, idVendor=0781, idProduct=5581
      usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
      This comes from the following place:
      [ 1660.215380] IP: xhci_set_usb2_hardware_lpm+0xdf/0x3d0 [xhci_hcd]
      [ 1660.222092] PGD 0 P4D 0
      [ 1660.224918] Oops: 0000 [#1] PREEMPT SMP NOPTI
      [ 1660.425520] CPU: 1 PID: 38 Comm: kworker/1:1 Tainted: P     U  W  O    4.14.67-apl #1
      [ 1660.434277] Workqueue: usb_hub_wq hub_event [usbcore]
      [ 1660.439918] task: ffffa295b6ae4c80 task.stack: ffffad4580150000
      [ 1660.446532] RIP: 0010:xhci_set_usb2_hardware_lpm+0xdf/0x3d0 [xhci_hcd]
      [ 1660.453821] RSP: 0018:ffffad4580153c70 EFLAGS: 00010046
      [ 1660.459655] RAX: 0000000000000000 RBX: ffffa295b4d7c000 RCX: 0000000000000002
      [ 1660.467625] RDX: 0000000000000002 RSI: ffffffff984a55b2 RDI: ffffffff984a55b2
      [ 1660.475586] RBP: ffffad4580153cc8 R08: 0000000000d6520a R09: 0000000000000001
      [ 1660.483556] R10: ffffad4580a004a0 R11: 0000000000000286 R12: ffffa295b4d7c000
      [ 1660.491525] R13: 0000000000010648 R14: ffffa295a84e1800 R15: 0000000000000000
      [ 1660.499494] FS:  0000000000000000(0000) GS:ffffa295bfc80000(0000) knlGS:0000000000000000
      [ 1660.508530] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 1660.514947] CR2: 0000000000000008 CR3: 000000025a114000 CR4: 00000000003406a0
      [ 1660.522917] Call Trace:
      [ 1660.525657]  usb_set_usb2_hardware_lpm+0x3d/0x70 [usbcore]
      [ 1660.531792]  usb_disable_device+0x242/0x260 [usbcore]
      [ 1660.537439]  usb_disconnect+0xc1/0x2b0 [usbcore]
      [ 1660.542600]  hub_event+0x596/0x18f0 [usbcore]
      [ 1660.547467]  ? trace_preempt_on+0xdf/0x100
      [ 1660.552040]  ? process_one_work+0x1c1/0x410
      [ 1660.556708]  process_one_work+0x1d2/0x410
      [ 1660.561184]  ? preempt_count_add.part.3+0x21/0x60
      [ 1660.566436]  worker_thread+0x2d/0x3f0
      [ 1660.570522]  kthread+0x122/0x140
      [ 1660.574123]  ? process_one_work+0x410/0x410
      [ 1660.578792]  ? kthread_create_on_node+0x60/0x60
      [ 1660.583849]  ret_from_fork+0x3a/0x50
      [ 1660.587839] Code: 00 49 89 c3 49 8b 84 24 50 16 00 00 8d 4a ff 48 8d 04 c8 48 89 ca 4c 8b 10 45 8b 6a 04 48 8b 00 48 89 45 c0 49 8b 86 80 03 00 00 <48> 8b 40 08 8b 40 03 0f 1f 44 00 00 45 85 ff 0f 84 81 01 00 00
      [ 1660.608980] RIP: xhci_set_usb2_hardware_lpm+0xdf/0x3d0 [xhci_hcd] RSP: ffffad4580153c70
      [ 1660.617921] CR2: 0000000000000008
      Tracking this down shows that udev->bos is NULL in the following code:
      (xhci.c, in xhci_set_usb2_hardware_lpm)
      	field = le32_to_cpu(udev->bos->ext_cap->bmAttributes);  <<<<<<< here
      	xhci_dbg(xhci, "%s port %d USB2 hardware LPM\n",
      			enable ? "enable" : "disable", port_num + 1);
      	if (enable) {
      		/* Host supports BESL timeout instead of HIRD */
      		if (udev->usb2_hw_lpm_besl_capable) {
      			/* if device doesn't have a preferred BESL value use a
      			 * default one which works with mixed HIRD and BESL
      			 * systems. See XHCI_DEFAULT_BESL definition in xhci.h
      			if ((field & USB_BESL_SUPPORT) &&
      			    (field & USB_BESL_BASELINE_VALID))
      				hird = USB_GET_BESL_BASELINE(field);
      				hird = udev->l1_params.besl;
      The failing case is when disabling LPM. So it is sufficient to avoid
      access to udev->bos by moving the instruction into the "enable" clause.
      Cc: Stable <stable@vger.kernel.org>
      Signed-off-by: default avatarCarsten Schmid <carsten_schmid@mentor.com>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Andrey Smirnov's avatar
      xhci: Convert xhci_handshake() to use readl_poll_timeout_atomic() · 017e6726
      Andrey Smirnov authored
      commit f7fac17ca925faa03fc5eb854c081a24075f8bad upstream.
      Xhci_handshake() implements the algorithm already captured by
      readl_poll_timeout_atomic(). Convert the former to use the latter to
      avoid repetition.
      Turned out this patch also fixes a bug on the AMD Stoneyridge platform
      where usleep(1) sometimes takes over 10ms.
      This means a 5 second timeout can easily take over 15 seconds which will
      trigger the watchdog and reboot the system.
      [Add info about patch fixing a bug to commit message -Mathias]
      Signed-off-by: default avatarAndrey Smirnov <andrew.smirnov@gmail.com>
      Tested-by: default avatarRaul E Rangel <rrangel@chromium.org>
      Reviewed-by: default avatarRaul E Rangel <rrangel@chromium.org>
      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>
    • Rasmus Villemoes's avatar
      include/linux/bitops.h: sanitize rotate primitives · ec70e2c1
      Rasmus Villemoes authored
      commit ef4d6f6b275c498f8e5626c99dbeefdc5027f843 upstream.
      The ror32 implementation (word >> shift) | (word << (32 - shift) has
      undefined behaviour if shift is outside the [1, 31] range.  Similarly
      for the 64 bit variants.  Most callers pass a compile-time constant
      (naturally in that range), but there's an UBSAN report that these may
      actually be called with a shift count of 0.
      Instead of special-casing that, we can make them DTRT for all values of
      shift while also avoiding UB.  For some reason, this was already partly
      done for rol32 (which was well-defined for [0, 31]).  gcc 8 recognizes
      these patterns as rotates, so for example
        __u32 rol32(__u32 word, unsigned int shift)
      	return (word << (shift & 31)) | (word >> ((-shift) & 31));
      compiles to
      0000000000000020 <rol32>:
        20:   89 f8                   mov    %edi,%eax
        22:   89 f1                   mov    %esi,%ecx
        24:   d3 c0                   rol    %cl,%eax
        26:   c3                      retq
      Older compilers unfortunately do not do as well, but this only affects
      the small minority of users that don't pass constants.
      Due to integer promotions, ro[lr]8 were already well-defined for shifts
      in [0, 8], and ro[lr]16 were mostly well-defined for shifts in [0, 16]
      (only mostly - u16 gets promoted to _signed_ int, so if bit 15 is set,
      word << 16 is undefined).  For consistency, update those as well.
      Link: http://lkml.kernel.org/r/20190410211906.2190-1-linux@rasmusvillemoes.dk
      Signed-off-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
      Reported-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Tested-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: default avatarWill Deacon <will.deacon@arm.com>
      Cc: Vadim Pasternak <vadimp@mellanox.com>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarMatthias Kaehlcke <mka@chromium.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Jessica Clarke's avatar
      sparc64: Fix regression in non-hypervisor TLB flush xcall · fbbc4fe0
      Jessica Clarke authored
      commit d3c976c14ad8af421134c428b0a89ff8dd3bd8f8 upstream.
      Previously, %g2 would end up with the value PAGE_SIZE, but after the
      commit mentioned below it ends up with the value 1 due to being reused
      for a different purpose. We need it to be PAGE_SIZE as we use it to step
      through pages in our demap loop, otherwise we set different flags in the
      low 12 bits of the address written to, thereby doing things other than a
      nucleus page flush.
      Fixes: a74ad5e6
       ("sparc64: Handle extremely large kernel TLB range flushes more gracefully.")
      Reported-by: default avatarMeelis Roos <mroos@linux.ee>
      Tested-by: default avatarMeelis Roos <mroos@linux.ee>
      Signed-off-by: Jessica Clarke's avatarJames Clarke <jrtc27@jrtc27.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Junwei Hu's avatar
      tipc: fix modprobe tipc failed after switch order of device registration -v2 · 5bce46ed
      Junwei Hu authored
      commit 526f5b851a96566803ee4bee60d0a34df56c77f8 upstream.
      Error message printed:
      modprobe: ERROR: could not insert 'tipc': Address family not
      supported by protocol.
      when modprobe tipc after the following patch: switch order of
      device registration, commit 7e27e8d6130c
      ("tipc: switch order of device registration to fix a crash")
      Because sock_create_kern(net, AF_TIPC, ...) called by
      tipc_topsrv_create_listener() in the initialization process
      of tipc_init_net(), so tipc_socket_init() must be execute before that.
      Meanwhile, tipc_net_id need to be initialized when sock_create()
      called, and tipc_socket_init() is no need to be called for each namespace.
      I add a variable tipc_topsrv_net_ops, and split the
      register_pernet_subsys() of tipc into two parts, and split
      tipc_socket_init() with initialization of pernet params.
      By the way, I fixed resources rollback error when tipc_bcast_init()
      failed in tipc_init_net().
      Fixes: 7e27e8d6130c ("tipc: switch order of device registration to fix a crash")
      Signed-off-by: default avatarJunwei Hu <hujunwei4@huawei.com>
      Reported-by: default avatarWang Wang <wangwang2@huawei.com>
      Reported-by: syzbot+1e8114b61079bfe9cbc5@syzkaller.appspotmail.com
      Reviewed-by: default avatarKang Zhou <zhoukang7@huawei.com>
      Reviewed-by: default avatarSuanming Mou <mousuanming@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • David S. Miller's avatar
      Revert "tipc: fix modprobe tipc failed after switch order of device registration" · 416d252b
      David S. Miller authored
      commit 5593530e56943182ebb6d81eca8a3be6db6dbba4 upstream.
      This reverts commit 532b0f7ece4cb2ffd24dc723ddf55242d1188e5e.
      More revisions coming up.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Konrad Rzeszutek Wilk's avatar
      xen/pciback: Don't disable PCI_COMMAND on PCI device reset. · f1613a9e
      Konrad Rzeszutek Wilk authored
      commit 7681f31ec9cdacab4fd10570be924f2cef6669ba upstream.
      There is no need for this at all. Worst it means that if
      the guest tries to write to BARs it could lead (on certain
      platforms) to PCI SERR errors.
      Please note that with af6fc858
      "xen-pciback: limit guest control of command register"
      a guest is still allowed to enable those control bits (safely), but
      is not allowed to disable them and that therefore a well behaved
      frontend which enables things before using them will still
      function correctly.
      This is done via an write to the configuration register 0x4 which
      triggers on the backend side:
        \- pci_enable_device
           \- pci_enable_device_flags
              \- do_pci_enable_device
                 \- pcibios_enable_device
                      [which enables the PCI_COMMAND_MEMORY|PCI_COMMAND_IO]
      However guests (and drivers) which don't do this could cause
      problems, including the security issues which XSA-120 sought
      to address.
      Reported-by: default avatarJan Beulich <jbeulich@suse.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Reviewed-by: default avatarPrarit Bhargava <prarit@redhat.com>
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Daniel Axtens's avatar
      crypto: vmx - ghash: do nosimd fallback manually · 383687e1
      Daniel Axtens authored
      commit 357d065a44cdd77ed5ff35155a989f2a763e96ef upstream.
      VMX ghash was using a fallback that did not support interleaving simd
      and nosimd operations, leading to failures in the extended test suite.
      If I understood correctly, Eric's suggestion was to use the same
      data format that the generic code uses, allowing us to call into it
      with the same contexts. I wasn't able to get that to work - I think
      there's a very different key structure and data layout being used.
      So instead steal the arm64 approach and perform the fallback
      operations directly if required.
      Fixes: cc333cd6
       ("crypto: vmx - Adding GHASH routines for VMX module")
      Cc: stable@vger.kernel.org # v4.1+
      Reported-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarDaniel Axtens <dja@axtens.net>
      Acked-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Tested-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDaniel Axtens <dja@axtens.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Antoine Tenart's avatar
      net: mvpp2: fix bad MVPP2_TXQ_SCHED_TOKEN_CNTR_REG queue value · 61ba8e9f
      Antoine Tenart authored
      [ Upstream commit 21808437214637952b61beaba6034d97880fbeb3 ]
      MVPP2_TXQ_SCHED_TOKEN_CNTR_REG() expects the logical queue id but
      the current code is passing the global tx queue offset, so it ends
      up writing to unknown registers (between 0x8280 and 0x82fc, which
      seemed to be unused by the hardware). This fixes the issue by using
      the logical queue id instead.
      Fixes: 3f518509
       ("ethernet: Add new driver for Marvell Armada 375 network unit")
      Signed-off-by: default avatarAntoine Tenart <antoine.tenart@bootlin.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Michael Chan's avatar
      bnxt_en: Fix aggregation buffer leak under OOM condition. · 1d33a3eb
      Michael Chan authored
      [ Upstream commit 296d5b54163964b7ae536b8b57dfbd21d4e868e1 ]
      For every RX packet, the driver replenishes all buffers used for that
      packet and puts them back into the RX ring and RX aggregation ring.
      In one code path where the RX packet has one RX buffer and one or more
      aggregation buffers, we missed recycling the aggregation buffer(s) if
      we are unable to allocate a new SKB buffer.  This leads to the
      aggregation ring slowly running out of buffers over time.  Fix it
      by properly recycling the aggregation buffers.
      Fixes: c0c050c5
       ("bnxt_en: New Broadcom ethernet driver.")
      Reported-by: default avatarRakesh Hemnani <rhemnani@fb.com>
      Signed-off-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>
    • Chris Packham's avatar
      tipc: Avoid copying bytes beyond the supplied data · 7d423301
      Chris Packham authored
      TLV_SET is called with a data pointer and a len parameter that tells us
      how many bytes are pointed to by data. When invoking memcpy() we need
      to careful to only copy len bytes.
      Previously we would copy TLV_LENGTH(len) bytes which would copy an extra
      4 bytes past the end of the data pointer which newer GCC versions
      complain about.
       In file included from test.c:17:
       In function 'TLV_SET',
           inlined from 'test' at test.c:186:5:
       warning: 'memcpy' forming offset [33, 36] is out of the bounds [0, 32]
       of object 'bearer_name' with type 'char[32]' [-Warray-bounds]
           memcpy(TLV_DATA(tlv_ptr), data, tlv_len);
       test.c: In function 'test':
       test.c::161:10: note:
       'bearer_name' declared here
           char bearer_name[TIPC_MAX_BEARER_NAME];
      We still want to ensure any padding bytes at the end are initialised, do
      this with a explicit memset() rather than copy bytes past the end of
      data. Apply the same logic to TCM_SET.
      Signed-off-by: default avatarChris Packham <chris.packham@alliedtelesis.co.nz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Kloetzke Jan's avatar
      usbnet: fix kernel crash after disconnect · 332bff9d
      Kloetzke Jan authored
      [ Upstream commit ad70411a978d1e6e97b1e341a7bde9a79af0c93d ]
      When disconnecting cdc_ncm the kernel sporadically crashes shortly
      after the disconnect:
        [   57.868812] Unable to handle kernel NULL pointer dereference at virtual address 00000000
        [   58.006653] PC is at 0x0
        [   58.009202] LR is at call_timer_fn+0xec/0x1b4
        [   58.013567] pc : [<0000000000000000>] lr : [<ffffff80080f5130>] pstate: 00000145
        [   58.020976] sp : ffffff8008003da0
        [   58.024295] x29: ffffff8008003da0 x28: 0000000000000001
        [   58.029618] x27: 000000000000000a x26: 0000000000000100
        [   58.034941] x25: 0000000000000000 x24: ffffff8008003e68
        [   58.040263] x23: 0000000000000000 x22: 0000000000000000
        [   58.045587] x21: 0000000000000000 x20: ffffffc68fac1808
        [   58.050910] x19: 0000000000000100 x18: 0000000000000000
        [   58.056232] x17: 0000007f885aff8c x16: 0000007f883a9f10
        [   58.061556] x15: 0000000000000001 x14: 000000000000006e
        [   58.066878] x13: 0000000000000000 x12: 00000000000000ba
        [   58.072201] x11: ffffffc69ff1db30 x10: 0000000000000020
        [   58.077524] x9 : 8000100008001000 x8 : 0000000000000001
        [   58.082847] x7 : 0000000000000800 x6 : ffffff8008003e70
        [   58.088169] x5 : ffffffc69ff17a28 x4 : 00000000ffff138b
        [   58.093492] x3 : 0000000000000000 x2 : 0000000000000000
        [   58.098814] x1 : 0000000000000000 x0 : 0000000000000000
        [   58.205800] [<          (null)>]           (null)
        [   58.210521] [<ffffff80080f5298>] expire_timers+0xa0/0x14c
        [   58.215937] [<ffffff80080f542c>] run_timer_softirq+0xe8/0x128
        [   58.221702] [<ffffff8008081120>] __do_softirq+0x298/0x348
        [   58.227118] [<ffffff80080a6304>] irq_exit+0x74/0xbc
        [   58.232009] [<ffffff80080e17dc>] __handle_domain_irq+0x78/0xac
        [   58.237857] [<ffffff8008080cf4>] gic_handle_irq+0x80/0xac
      The crash happens roughly 125..130ms after the disconnect. This
      correlates with the 'delay' timer that is started on certain USB tx/rx
      errors in the URB completion handler.
      The problem is a race of usbnet_stop() with usbnet_start_xmit(). In
      usbnet_stop() we call usbnet_terminate_urbs() to cancel all URBs in
      flight. This only makes sense if no new URBs are submitted
      concurrently, though. But the usbnet_start_xmit() can run at the same
      time on another CPU which almost unconditionally submits an URB. The
      error callback of the new URB will then schedule the timer after it was
      already stopped.
      The fix adds a check if the tx queue is stopped after the tx list lock
      has been taken. This should reliably prevent the submission of new URBs
      while usbnet_terminate_urbs() does its job. The same thing is done on
      the rx side even though it might be safe due to other flags that are
      checked there.
      Signed-off-by: default avatarJan Klötzke <Jan.Kloetzke@preh.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Jisheng Zhang's avatar
      net: stmmac: fix reset gpio free missing · 16ffb5f7
      Jisheng Zhang authored
      [ Upstream commit 49ce881c0d4c4a7a35358d9dccd5f26d0e56fc61 ]
      Commit 984203ce ("net: stmmac: mdio: remove reset gpio free")
      removed the reset gpio free, when the driver is unbinded or rmmod,
      we miss the gpio free.
      This patch uses managed API to request the reset gpio, so that the
      gpio could be freed properly.
      Fixes: 984203ce
       ("net: stmmac: mdio: remove reset gpio free")
      Signed-off-by: default avatarJisheng Zhang <Jisheng.Zhang@synaptics.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Eric Dumazet's avatar
      net-gro: fix use-after-free read in napi_gro_frags() · 4f9c73aa
      Eric Dumazet authored
      [ Upstream commit a4270d6795b0580287453ea55974d948393e66ef ]
      If a network driver provides to napi_gro_frags() an
      skb with a page fragment of exactly 14 bytes, the call
      to gro_pull_from_frag0() will 'consume' the fragment
      by calling skb_frag_unref(skb, 0), and the page might
      be freed and reused.
      Reading eth->h_proto at the end of napi_frags_skb() might
      read mangled data, or crash under specific debugging features.
      BUG: KASAN: use-after-free in napi_frags_skb net/core/dev.c:5833 [inline]
      BUG: KASAN: use-after-free in napi_gro_frags+0xc6f/0xd10 net/core/dev.c:5841
      Read of size 2 at addr ffff88809366840c by task syz-executor599/8957
      CPU: 1 PID: 8957 Comm: syz-executor599 Not tainted 5.2.0-rc1+ #32
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x172/0x1f0 lib/dump_stack.c:113
       print_address_description.cold+0x7c/0x20d mm/kasan/report.c:188
       __kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
       kasan_report+0x12/0x20 mm/kasan/common.c:614
       __asan_report_load_n_noabort+0xf/0x20 mm/kasan/generic_report.c:142
       napi_frags_skb net/core/dev.c:5833 [inline]
       napi_gro_frags+0xc6f/0xd10 net/core/dev.c:5841
       tun_get_user+0x2f3c/0x3ff0 drivers/net/tun.c:1991
       tun_chr_write_iter+0xbd/0x156 drivers/net/tun.c:2037
       call_write_iter include/linux/fs.h:1872 [inline]
       do_iter_readv_writev+0x5f8/0x8f0 fs/read_write.c:693
       do_iter_write fs/read_write.c:970 [inline]
       do_iter_write+0x184/0x610 fs/read_write.c:951
       vfs_writev+0x1b3/0x2f0 fs/read_write.c:1015
       do_writev+0x15b/0x330 fs/read_write.c:1058
      Fixes: a50e233c
       ("net-gro: restore frag0 optimization")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Eric Dumazet's avatar
      llc: fix skb leak in llc_build_and_send_ui_pkt() · 5cbaa135
      Eric Dumazet authored
      [ Upstream commit 8fb44d60d4142cd2a440620cd291d346e23c131e ]
      If llc_mac_hdr_init() returns an error, we must drop the skb
      since no llc_build_and_send_ui_pkt() caller will take care of this.
      BUG: memory leak
      unreferenced object 0xffff8881202b6800 (size 2048):
        comm "syz-executor907", pid 7074, jiffies 4294943781 (age 8.590s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
          1a 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00  ...@............
          [<00000000e25b5abe>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline]
          [<00000000e25b5abe>] slab_post_alloc_hook mm/slab.h:439 [inline]
          [<00000000e25b5abe>] slab_alloc mm/slab.c:3326 [inline]
          [<00000000e25b5abe>] __do_kmalloc mm/slab.c:3658 [inline]
          [<00000000e25b5abe>] __kmalloc+0x161/0x2c0 mm/slab.c:3669
          [<00000000a1ae188a>] kmalloc include/linux/slab.h:552 [inline]
          [<00000000a1ae188a>] sk_prot_alloc+0xd6/0x170 net/core/sock.c:1608
          [<00000000ded25bbe>] sk_alloc+0x35/0x2f0 net/core/sock.c:1662
          [<000000002ecae075>] llc_sk_alloc+0x35/0x170 net/llc/llc_conn.c:950
          [<00000000551f7c47>] llc_ui_create+0x7b/0x140 net/llc/af_llc.c:173
          [<0000000029027f0e>] __sock_create+0x164/0x250 net/socket.c:1430
          [<000000008bdec225>] sock_create net/socket.c:1481 [inline]
          [<000000008bdec225>] __sys_socket+0x69/0x110 net/socket.c:1523
          [<00000000b6439228>] __do_sys_socket net/socket.c:1532 [inline]
          [<00000000b6439228>] __se_sys_socket net/socket.c:1530 [inline]
          [<00000000b6439228>] __x64_sys_socket+0x1e/0x30 net/socket.c:1530
          [<00000000cec820c1>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:301
          [<000000000c32554f>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
      BUG: memory leak
      unreferenced object 0xffff88811d750d00 (size 224):
        comm "syz-executor907", pid 7074, jiffies 4294943781 (age 8.600s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
          00 f0 0c 24 81 88 ff ff 00 68 2b 20 81 88 ff ff  ...$.....h+ ....
          [<0000000053026172>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline]
          [<0000000053026172>] slab_post_alloc_hook mm/slab.h:439 [inline]
          [<0000000053026172>] slab_alloc_node mm/slab.c:3269 [inline]
          [<0000000053026172>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
          [<00000000fa8f3c30>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:198
          [<00000000d96fdafb>] alloc_skb include/linux/skbuff.h:1058 [inline]
          [<00000000d96fdafb>] alloc_skb_with_frags+0x5f/0x250 net/core/skbuff.c:5327
          [<000000000a34a2e7>] sock_alloc_send_pskb+0x269/0x2a0 net/core/sock.c:2225
          [<00000000ee39999b>] sock_alloc_send_skb+0x32/0x40 net/core/sock.c:2242
          [<00000000e034d810>] llc_ui_sendmsg+0x10a/0x540 net/llc/af_llc.c:933
          [<00000000c0bc8445>] sock_sendmsg_nosec net/socket.c:652 [inline]
          [<00000000c0bc8445>] sock_sendmsg+0x54/0x70 net/socket.c:671
          [<000000003b687167>] __sys_sendto+0x148/0x1f0 net/socket.c:1964
          [<00000000922d78d9>] __do_sys_sendto net/socket.c:1976 [inline]
          [<00000000922d78d9>] __se_sys_sendto net/socket.c:1972 [inline]
          [<00000000922d78d9>] __x64_sys_sendto+0x2a/0x30 net/socket.c:1972
          [<00000000cec820c1>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:301
          [<000000000c32554f>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
      Fixes: 1da177e4
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Mike Manning's avatar
      ipv6: Consider sk_bound_dev_if when binding a raw socket to an address · 36a72220
      Mike Manning authored
      [ Upstream commit 72f7cfab6f93a8ea825fab8ccfb016d064269f7f ]
      IPv6 does not consider if the socket is bound to a device when binding
      to an address. The result is that a socket can be bound to eth0 and
      then bound to the address of eth1. If the device is a VRF, the result
      is that a socket can only be bound to an address in the default VRF.
      Resolve by considering the device if sk_bound_dev_if is set.
      Signed-off-by: default avatarMike Manning <mmanning@vyatta.att-mail.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@gmail.com>
      Tested-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Arnd Bergmann's avatar
      ASoC: davinci-mcasp: Fix clang warning without CONFIG_PM · 9fbf1ac5
      Arnd Bergmann authored
      [ Upstream commit 8ca5104715cfd14254ea5aecc390ae583b707607 ]
      Building with clang shows a variable that is only used by the
      suspend/resume functions but defined outside of their #ifdef block:
      sound/soc/ti/davinci-mcasp.c:48:12: error: variable 'context_regs' is not needed and will not be emitted
      We commonly fix these by marking the PM functions as __maybe_unused,
      but here that would grow the davinci_mcasp structure, so instead
      add another #ifdef here.
      Fixes: 1cc0c054
       ("ASoC: davinci-mcasp: Convert the context save/restore to use array")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      Reviewed-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
    • Chris Lesiak's avatar
      spi: Fix zero length xfer bug · 0984cb76
      Chris Lesiak authored
      [ Upstream commit 5442dcaa0d90fc376bdfc179a018931a8f43dea4 ]
      This fixes a bug for messages containing both zero length and
      unidirectional xfers.
      The function spi_map_msg will allocate dummy tx and/or rx buffers
      for use with unidirectional transfers when the hardware can only do
      a bidirectional transfer.  That dummy buffer will be used in place
      of a NULL buffer even when the xfer length is 0.
      Then in the function __spi_map_msg, if he hardware can dma,
      the zero length xfer will have spi_map_buf called on the dummy
      Eventually, __sg_alloc_table is called and returns -EINVAL
      because nents == 0.
      This fix prevents the error by not using the dummy buffer when
      the xfer length is zero.
      Signed-off-by: default avatarChris Lesiak <chris.lesiak@licor.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
    • Geert Uytterhoeven's avatar
      spi: rspi: Fix sequencer reset during initialization · 854415f3
      Geert Uytterhoeven authored
      [ Upstream commit 26843bb128590edd7eba1ad7ce22e4b9f1066ce3 ]
      While the sequencer is reset after each SPI message since commit
      880c6d11 ("spi: rspi: Add support for Quad and Dual SPI
      Transfers on QSPI"), it was never reset for the first message, thus
      relying on reset state or bootloader settings.
      Fix this by initializing it explicitly during configuration.
      Fixes: 0b2182dd
       ("spi: add support for Renesas RSPI")
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>