1. 21 Aug, 2020 40 commits
    • Hangbin Liu's avatar
      Revert "vxlan: fix tos value before xmit" · b901e8e4
      Hangbin Liu authored
      [ Upstream commit a0dced17 ]
      
      This reverts commit 71130f29.
      
      In commit 71130f29 ("vxlan: fix tos value before xmit") we want to
      make sure the tos value are filtered by RT_TOS() based on RFC1349.
      
             0     1     2     3     4     5     6     7
          +-----+-----+-----+-----+-----+-----+-----+-----+
          |   PRECEDENCE    |          TOS          | MBZ |
          +-----+-----+-----+-----+-----+-----+-----+-----+
      
      But RFC1349 has been obsoleted by RFC2474. The new DSCP field defined like
      
             0     1     2     3     4     5     6     7
          +-----+-----+-----+-----+-----+-----+-----+-----+
          |          DS FIELD, DSCP           | ECN FIELD |
          +-----+-----+-----+-----+-----+-----+-----+-----+
      
      So with
      
      IPTOS_TOS_MASK          0x1E
      RT_TOS(tos)		((tos)&IPTOS_TOS_MASK)
      
      the first 3 bits DSCP info will get lost.
      
      To take all the DSCP info in xmit, we should revert the patch and just push
      all tos bits to ip_tunnel_ecn_encap(), which will handling ECN field later.
      
      Fixes: 71130f29 ("vxlan: fix tos value before xmit")
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Acked-by: default avatarGuillaume Nault <gnault@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b901e8e4
    • Johan Hovold's avatar
      net: lan78xx: replace bogus endpoint lookup · 2edf9427
      Johan Hovold authored
      [ Upstream commit ea060b35 ]
      
      Drop the bogus endpoint-lookup helper which could end up accepting
      interfaces based on endpoints belonging to unrelated altsettings.
      
      Note that the returned bulk pipes and interrupt endpoint descriptor
      were never actually used. Instead the bulk-endpoint numbers are
      hardcoded to 1 and 2 (matching the specification), while the interrupt-
      endpoint descriptor was assumed to be the third descriptor created by
      USB core.
      
      Try to bring some order to this by dropping the bogus lookup helper and
      adding the missing endpoint sanity checks while keeping the interrupt-
      descriptor assumption for now.
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2edf9427
    • Ido Schimmel's avatar
      vxlan: Ensure FDB dump is performed under RCU · d3c4938d
      Ido Schimmel authored
      [ Upstream commit b5141915 ]
      
      The commit cited below removed the RCU read-side critical section from
      rtnl_fdb_dump() which means that the ndo_fdb_dump() callback is invoked
      without RCU protection.
      
      This results in the following warning [1] in the VXLAN driver, which
      relied on the callback being invoked from an RCU read-side critical
      section.
      
      Fix this by calling rcu_read_lock() in the VXLAN driver, as already done
      in the bridge driver.
      
      [1]
      WARNING: suspicious RCU usage
      5.8.0-rc4-custom-01521-g481007553ce6 #29 Not tainted
      -----------------------------
      drivers/net/vxlan.c:1379 RCU-list traversed in non-reader section!!
      
      other info that might help us debug this:
      
      rcu_scheduler_active = 2, debug_locks = 1
      1 lock held by bridge/166:
       #0: ffffffff85a27850 (rtnl_mutex){+.+.}-{3:3}, at: netlink_dump+0xea/0x1090
      
      stack backtrace:
      CPU: 1 PID: 166 Comm: bridge Not tainted 5.8.0-rc4-custom-01521-g481007553ce6 #29
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-2.fc32 04/01/2014
      Call Trace:
       dump_stack+0x100/0x184
       lockdep_rcu_suspicious+0x153/0x15d
       vxlan_fdb_dump+0x51e/0x6d0
       rtnl_fdb_dump+0x4dc/0xad0
       netlink_dump+0x540/0x1090
       __netlink_dump_start+0x695/0x950
       rtnetlink_rcv_msg+0x802/0xbd0
       netlink_rcv_skb+0x17a/0x480
       rtnetlink_rcv+0x22/0x30
       netlink_unicast+0x5ae/0x890
       netlink_sendmsg+0x98a/0xf40
       __sys_sendto+0x279/0x3b0
       __x64_sys_sendto+0xe6/0x1a0
       do_syscall_64+0x54/0xa0
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      RIP: 0033:0x7fe14fa2ade0
      Code: Bad RIP value.
      RSP: 002b:00007fff75bb5b88 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
      RAX: ffffffffffffffda RBX: 00005614b1ba0020 RCX: 00007fe14fa2ade0
      RDX: 000000000000011c RSI: 00007fff75bb5b90 RDI: 0000000000000003
      RBP: 00007fff75bb5b90 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00005614b1b89160
      R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
      
      Fixes: 5e6d2435 ("bridge: netlink dump interface at par with brctl")
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d3c4938d
    • Cong Wang's avatar
      ipv6: fix memory leaks on IPV6_ADDRFORM path · 86e4cc08
      Cong Wang authored
      [ Upstream commit 8c0de6e9 ]
      
      IPV6_ADDRFORM causes resource leaks when converting an IPv6 socket
      to IPv4, particularly struct ipv6_ac_socklist. Similar to
      struct ipv6_mc_socklist, we should just close it on this path.
      
      This bug can be easily reproduced with the following C program:
      
        #include <stdio.h>
        #include <string.h>
        #include <sys/types.h>
        #include <sys/socket.h>
        #include <arpa/inet.h>
      
        int main()
        {
          int s, value;
          struct sockaddr_in6 addr;
          struct ipv6_mreq m6;
      
          s = socket(AF_INET6, SOCK_DGRAM, 0);
          addr.sin6_family = AF_INET6;
          addr.sin6_port = htons(5000);
          inet_pton(AF_INET6, "::ffff:192.168.122.194", &addr.sin6_addr);
          connect(s, (struct sockaddr *)&addr, sizeof(addr));
      
          inet_pton(AF_INET6, "fe80::AAAA", &m6.ipv6mr_multiaddr);
          m6.ipv6mr_interface = 5;
          setsockopt(s, SOL_IPV6, IPV6_JOIN_ANYCAST, &m6, sizeof(m6));
      
          value = AF_INET;
          setsockopt(s, SOL_IPV6, IPV6_ADDRFORM, &value, sizeof(value));
      
          close(s);
          return 0;
        }
      
      Reported-by: ch3332xr@gmail.com
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      86e4cc08
    • Ido Schimmel's avatar
      ipv4: Silence suspicious RCU usage warning · f81f591e
      Ido Schimmel authored
      [ Upstream commit 83f35228 ]
      
      fib_trie_unmerge() is called with RTNL held, but not from an RCU
      read-side critical section. This leads to the following warning [1] when
      the FIB alias list in a leaf is traversed with
      hlist_for_each_entry_rcu().
      
      Since the function is always called with RTNL held and since
      modification of the list is protected by RTNL, simply use
      hlist_for_each_entry() and silence the warning.
      
      [1]
      WARNING: suspicious RCU usage
      5.8.0-rc4-custom-01520-gc1f937f3f83b #30 Not tainted
      -----------------------------
      net/ipv4/fib_trie.c:1867 RCU-list traversed in non-reader section!!
      
      other info that might help us debug this:
      
      rcu_scheduler_active = 2, debug_locks = 1
      1 lock held by ip/164:
       #0: ffffffff85a27850 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x49a/0xbd0
      
      stack backtrace:
      CPU: 0 PID: 164 Comm: ip Not tainted 5.8.0-rc4-custom-01520-gc1f937f3f83b #30
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-2.fc32 04/01/2014
      Call Trace:
       dump_stack+0x100/0x184
       lockdep_rcu_suspicious+0x153/0x15d
       fib_trie_unmerge+0x608/0xdb0
       fib_unmerge+0x44/0x360
       fib4_rule_configure+0xc8/0xad0
       fib_nl_newrule+0x37a/0x1dd0
       rtnetlink_rcv_msg+0x4f7/0xbd0
       netlink_rcv_skb+0x17a/0x480
       rtnetlink_rcv+0x22/0x30
       netlink_unicast+0x5ae/0x890
       netlink_sendmsg+0x98a/0xf40
       ____sys_sendmsg+0x879/0xa00
       ___sys_sendmsg+0x122/0x190
       __sys_sendmsg+0x103/0x1d0
       __x64_sys_sendmsg+0x7d/0xb0
       do_syscall_64+0x54/0xa0
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      RIP: 0033:0x7fc80a234e97
      Code: Bad RIP value.
      RSP: 002b:00007ffef8b66798 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fc80a234e97
      RDX: 0000000000000000 RSI: 00007ffef8b66800 RDI: 0000000000000003
      RBP: 000000005f141b1c R08: 0000000000000001 R09: 0000000000000000
      R10: 00007fc80a2a8ac0 R11: 0000000000000246 R12: 0000000000000001
      R13: 0000000000000000 R14: 00007ffef8b67008 R15: 0000556fccb10020
      
      Fixes: 0ddcf43d ("ipv4: FIB Local/MAIN table collapse")
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f81f591e
    • Jann Horn's avatar
      binder: Prevent context manager from incrementing ref 0 · 1427acbb
      Jann Horn authored
      commit 4b836a14 upstream.
      
      Binder is designed such that a binder_proc never has references to
      itself. If this rule is violated, memory corruption can occur when a
      process sends a transaction to itself; see e.g.
      <https://syzkaller.appspot.com/bug?extid=09e05aba06723a94d43d>.
      
      There is a remaining edgecase through which such a transaction-to-self
      can still occur from the context of a task with BINDER_SET_CONTEXT_MGR
      access:
      
       - task A opens /dev/binder twice, creating binder_proc instances P1
         and P2
       - P1 becomes context manager
       - P2 calls ACQUIRE on the magic handle 0, allocating index 0 in its
         handle table
       - P1 dies (by closing the /dev/binder fd and waiting a bit)
       - P2 becomes context manager
       - P2 calls ACQUIRE on the magic handle 0, allocating index 1 in its
         handle table
         [this triggers a warning: "binder: 1974:1974 tried to acquire
         reference to desc 0, got 1 instead"]
       - task B opens /dev/binder once, creating binder_proc instance P3
       - P3 calls P2 (via magic handle 0) with (void*)1 as argument (two-way
         transaction)
       - P2 receives the handle and uses it to call P3 (two-way transaction)
       - P3 calls P2 (via magic handle 0) (two-way transaction)
       - P2 calls P2 (via handle 1) (two-way transaction)
      
      And then, if P2 does *NOT* accept the incoming transaction work, but
      instead closes the binder fd, we get a crash.
      
      Solve it by preventing the context manager from using ACQUIRE on ref 0.
      There shouldn't be any legitimate reason for the context manager to do
      that.
      
      Additionally, print a warning if someone manages to find another way to
      trigger a transaction-to-self bug in the future.
      
      Cc: stable@vger.kernel.org
      Fixes: 457b9a6f ("Staging: android: add binder driver")
      Acked-by: default avatarTodd Kjos <tkjos@google.com>
      Signed-off-by: default avatarJann Horn <jannh@google.com>
      Reviewed-by: default avatarMartijn Coenen <maco@android.com>
      Link: https://lore.kernel.org/r/20200727120424.1627555-1-jannh@google.com
      [manual backport: remove fine-grained locking and error reporting that
                        don't exist in <=4.9]
      Signed-off-by: default avatarJann Horn <jannh@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1427acbb
    • Frank van der Linden's avatar
      xattr: break delegations in {set,remove}xattr · 419d10ae
      Frank van der Linden authored
      commit 08b5d501 upstream.
      
      set/removexattr on an exported filesystem should break NFS delegations.
      This is true in general, but also for the upcoming support for
      RFC 8726 (NFSv4 extended attribute support). Make sure that they do.
      
      Additionally, they need to grow a _locked variant, since callers might
      call this with i_rwsem held (like the NFS server code).
      
      Cc: stable@vger.kernel.org # v4.9+
      Cc: linux-fsdevel@vger.kernel.org
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarFrank van der Linden <fllinden@amazon.com>
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      419d10ae
    • Philippe Duplessis-Guindon's avatar
      tools lib traceevent: Fix memory leak in process_dynamic_array_len · a710335b
      Philippe Duplessis-Guindon authored
      [ Upstream commit e24c6447 ]
      
      I compiled with AddressSanitizer and I had these memory leaks while I
      was using the tep_parse_format function:
      
          Direct leak of 28 byte(s) in 4 object(s) allocated from:
              #0 0x7fb07db49ffe in __interceptor_realloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dffe)
              #1 0x7fb07a724228 in extend_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:985
              #2 0x7fb07a724c21 in __read_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1140
              #3 0x7fb07a724f78 in read_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1206
              #4 0x7fb07a725191 in __read_expect_type /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1291
              #5 0x7fb07a7251df in read_expect_type /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1299
              #6 0x7fb07a72e6c8 in process_dynamic_array_len /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:2849
              #7 0x7fb07a7304b8 in process_function /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3161
              #8 0x7fb07a730900 in process_arg_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3207
              #9 0x7fb07a727c0b in process_arg /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1786
              #10 0x7fb07a731080 in event_read_print_args /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3285
              #11 0x7fb07a731722 in event_read_print /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3369
              #12 0x7fb07a740054 in __tep_parse_format /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6335
              #13 0x7fb07a74047a in __parse_event /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6389
              #14 0x7fb07a740536 in tep_parse_format /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6431
              #15 0x7fb07a785acf in parse_event ../../../src/fs-src/fs.c:251
              #16 0x7fb07a785ccd in parse_systems ../../../src/fs-src/fs.c:284
              #17 0x7fb07a786fb3 in read_metadata ../../../src/fs-src/fs.c:593
              #18 0x7fb07a78760e in ftrace_fs_source_init ../../../src/fs-src/fs.c:727
              #19 0x7fb07d90c19c in add_component_with_init_method_data ../../../../src/lib/graph/graph.c:1048
              #20 0x7fb07d90c87b in add_source_component_with_initialize_method_data ../../../../src/lib/graph/graph.c:1127
              #21 0x7fb07d90c92a in bt_graph_add_source_component ../../../../src/lib/graph/graph.c:1152
              #22 0x55db11aa632e in cmd_run_ctx_create_components_from_config_components ../../../src/cli/babeltrace2.c:2252
              #23 0x55db11aa6fda in cmd_run_ctx_create_components ../../../src/cli/babeltrace2.c:2347
              #24 0x55db11aa780c in cmd_run ../../../src/cli/babeltrace2.c:2461
              #25 0x55db11aa8a7d in main ../../../src/cli/babeltrace2.c:2673
              #26 0x7fb07d5460b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
      
      The token variable in the process_dynamic_array_len function is
      allocated in the read_expect_type function, but is not freed before
      calling the read_token function.
      
      Free the token variable before calling read_token in order to plug the
      leak.
      Signed-off-by: default avatarPhilippe Duplessis-Guindon <pduplessis@efficios.com>
      Reviewed-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Link: https://lore.kernel.org/linux-trace-devel/20200730150236.5392-1-pduplessis@efficios.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a710335b
    • Xin Xiong's avatar
      atm: fix atm_dev refcnt leaks in atmtcp_remove_persistent · c8313917
      Xin Xiong authored
      [ Upstream commit 51875dad ]
      
      atmtcp_remove_persistent() invokes atm_dev_lookup(), which returns a
      reference of atm_dev with increased refcount or NULL if fails.
      
      The refcount leaks issues occur in two error handling paths. If
      dev_data->persist is zero or PRIV(dev)->vcc isn't NULL, the function
      returns 0 without decreasing the refcount kept by a local variable,
      resulting in refcount leaks.
      
      Fix the issue by adding atm_dev_put() before returning 0 both when
      dev_data->persist is zero or PRIV(dev)->vcc isn't NULL.
      Signed-off-by: default avatarXin Xiong <xiongx18@fudan.edu.cn>
      Signed-off-by: default avatarXiyu Yang <xiyuyang19@fudan.edu.cn>
      Signed-off-by: default avatarXin Tan <tanxin.ctf@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c8313917
    • Francesco Ruggeri's avatar
      igb: reinit_locked() should be called with rtnl_lock · 137e399e
      Francesco Ruggeri authored
      [ Upstream commit 024a8168 ]
      
      We observed two panics involving races with igb_reset_task.
      The first panic is caused by this race condition:
      
      	kworker			reboot -f
      
      	igb_reset_task
      	igb_reinit_locked
      	igb_down
      	napi_synchronize
      				__igb_shutdown
      				igb_clear_interrupt_scheme
      				igb_free_q_vectors
      				igb_free_q_vector
      				adapter->q_vector[v_idx] = NULL;
      	napi_disable
      	Panics trying to access
      	adapter->q_vector[v_idx].napi_state
      
      The second panic (a divide error) is caused by this race:
      
      kworker		reboot -f	tx packet
      
      igb_reset_task
      		__igb_shutdown
      		rtnl_lock()
      		...
      		igb_clear_interrupt_scheme
      		igb_free_q_vectors
      		adapter->num_tx_queues = 0
      		...
      		rtnl_unlock()
      rtnl_lock()
      igb_reinit_locked
      igb_down
      igb_up
      netif_tx_start_all_queues
      				dev_hard_start_xmit
      				igb_xmit_frame
      				igb_tx_queue_mapping
      				Panics on
      				r_idx % adapter->num_tx_queues
      
      This commit applies to igb_reset_task the same changes that
      were applied to ixgbe in commit 2f90b865 ("ixgbe: this patch
      adds support for DCB to the kernel and ixgbe driver"),
      commit 8f4c5c9f ("ixgbe: reinit_locked() should be called with
      rtnl_lock") and commit 88adce4e ("ixgbe: fix possible race in
      reset subtask").
      Signed-off-by: default avatarFrancesco Ruggeri <fruggeri@arista.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      137e399e
    • Julian Squires's avatar
      cfg80211: check vendor command doit pointer before use · 71a5362d
      Julian Squires authored
      [ Upstream commit 4052d3d2 ]
      
      In the case where a vendor command does not implement doit, and has no
      flags set, doit would not be validated and a NULL pointer dereference
      would occur, for example when invoking the vendor command via iw.
      
      I encountered this while developing new vendor commands.  Perhaps in
      practice it is advisable to always implement doit along with dumpit,
      but it seems reasonable to me to always check doit anyway, not just
      when NEED_WDEV.
      Signed-off-by: default avatarJulian Squires <julian@cipht.net>
      Link: https://lore.kernel.org/r/20200706211353.2366470-1-julian@cipht.netSigned-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      71a5362d
    • Ben Skeggs's avatar
      drm/nouveau/fbcon: fix module unload when fbcon init has failed for some reason · 705a601e
      Ben Skeggs authored
      [ Upstream commit 498595ab ]
      
      Stale pointer was tripping up the unload path.
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      705a601e
    • Christoph Hellwig's avatar
      net/9p: validate fds in p9_fd_open · edd90971
      Christoph Hellwig authored
      [ Upstream commit a39c4606 ]
      
      p9_fd_open just fgets file descriptors passed in from userspace, but
      doesn't verify that they are valid for read or writing.  This gets
      cought down in the VFS when actually attempting a read or write, but
      a new warning added in linux-next upsets syzcaller.
      
      Fix this by just verifying the fds early on.
      
      Link: http://lkml.kernel.org/r/20200710085722.435850-1-hch@lst.de
      Reported-by: syzbot+e6f77e16ff68b2434a2c@syzkaller.appspotmail.com
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      [Dominique: amend goto as per Doug Nazar's review]
      Signed-off-by: default avatarDominique Martinet <asmadeus@codewreck.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      edd90971
    • Johan Hovold's avatar
      leds: 88pm860x: fix use-after-free on unbind · efde0ddb
      Johan Hovold authored
      commit eca21c2d upstream.
      
      Several MFD child drivers register their class devices directly under
      the parent device. This means you cannot blindly do devres conversions
      so that deregistration ends up being tied to the parent device,
      something which leads to use-after-free on driver unbind when the class
      device is released while still being registered.
      
      Fixes: 375446df ("leds: 88pm860x: Use devm_led_classdev_register")
      Cc: stable <stable@vger.kernel.org>     # 4.6
      Cc: Amitoj Kaur Chawla <amitoj1606@gmail.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarPavel Machek <pavel@ucw.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      efde0ddb
    • Johan Hovold's avatar
      leds: lm3533: fix use-after-free on unbind · ae1cd9f6
      Johan Hovold authored
      commit d584221e upstream.
      
      Several MFD child drivers register their class devices directly under
      the parent device. This means you cannot blindly do devres conversions
      so that deregistration ends up being tied to the parent device,
      something which leads to use-after-free on driver unbind when the class
      device is released while still being registered.
      
      Fixes: 50154e29 ("leds: lm3533: Use devm_led_classdev_register")
      Cc: stable <stable@vger.kernel.org>     # 4.6
      Cc: Amitoj Kaur Chawla <amitoj1606@gmail.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarPavel Machek <pavel@ucw.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ae1cd9f6
    • Johan Hovold's avatar
      leds: da903x: fix use-after-free on unbind · 6b3f0df8
      Johan Hovold authored
      commit 6f4aa357 upstream.
      
      Several MFD child drivers register their class devices directly under
      the parent device. This means you cannot blindly do devres conversions
      so that deregistration ends up being tied to the parent device,
      something which leads to use-after-free on driver unbind when the class
      device is released while still being registered.
      
      Fixes: eed16255 ("leds: da903x: Use devm_led_classdev_register")
      Cc: stable <stable@vger.kernel.org>     # 4.6
      Cc: Amitoj Kaur Chawla <amitoj1606@gmail.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarPavel Machek <pavel@ucw.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6b3f0df8
    • Johan Hovold's avatar
      leds: wm831x-status: fix use-after-free on unbind · 6de8169a
      Johan Hovold authored
      commit 47a459ec upstream.
      
      Several MFD child drivers register their class devices directly under
      the parent device. This means you cannot blindly do devres conversions
      so that deregistration ends up being tied to the parent device,
      something which leads to use-after-free on driver unbind when the class
      device is released while still being registered.
      
      Fixes: 8d3b6a40 ("leds: wm831x-status: Use devm_led_classdev_register")
      Cc: stable <stable@vger.kernel.org>     # 4.6
      Cc: Amitoj Kaur Chawla <amitoj1606@gmail.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarPavel Machek <pavel@ucw.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6de8169a
    • Greg Kroah-Hartman's avatar
      mtd: properly check all write ioctls for permissions · 583d4240
      Greg Kroah-Hartman authored
      commit f7e6b19b upstream.
      
      When doing a "write" ioctl call, properly check that we have permissions
      to do so before copying anything from userspace or anything else so we
      can "fail fast".  This includes also covering the MEMWRITE ioctl which
      previously missed checking for this.
      
      Cc: Miquel Raynal <miquel.raynal@bootlin.com>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Vignesh Raghavendra <vigneshr@ti.com>
      Cc: stable <stable@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      [rw: Fixed locking issue]
      Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      583d4240
    • Yunhai Zhang's avatar
      vgacon: Fix for missing check in scrollback handling · 8c19b606
      Yunhai Zhang authored
      commit ebfdfeea upstream.
      
      vgacon_scrollback_update() always leaves enbough room in the scrollback
      buffer for the next call, but if the console size changed that room
      might not actually be enough, and so we need to re-check.
      
      The check should be in the loop since vgacon_scrollback_cur->tail is
      updated in the loop and count may be more than 1 when triggered by CSI M,
      as Jiri's PoC:
      #include <stdio.h>
      #include <stdlib.h>
      #include <unistd.h>
      #include <sys/types.h>
      #include <sys/stat.h>
      #include <sys/ioctl.h>
      #include <fcntl.h>
      
      int main(int argc, char** argv)
      {
              int fd = open("/dev/tty1", O_RDWR);
              unsigned short size[3] = {25, 200, 0};
              ioctl(fd, 0x5609, size); // VT_RESIZE
      
              write(fd, "\e[1;1H", 6);
              for (int i = 0; i < 30; i++)
                      write(fd, "\e[10M", 5);
      }
      
      It leads to various crashes as vgacon_scrollback_update writes out of
      the buffer:
       BUG: unable to handle page fault for address: ffffc900001752a0
       #PF: supervisor write access in kernel mode
       #PF: error_code(0x0002) - not-present page
       RIP: 0010:mutex_unlock+0x13/0x30
      ...
       Call Trace:
        n_tty_write+0x1a0/0x4d0
        tty_write+0x1a0/0x2e0
      
      Or to KASAN reports:
      BUG: KASAN: slab-out-of-bounds in vgacon_scroll+0x57a/0x8ed
      
      This fixes CVE-2020-14331.
      Reported-by: default avatar张云海 <zhangyunhai@nsfocus.com>
      Reported-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      Reported-by: default avatarKyungtae Kim <kt0755@gmail.com>
      Fixes: 15bdab95 ([PATCH] vgacon: Add support for soft scrollback)
      Cc: stable@vger.kernel.org
      Cc: linux-fbdev@vger.kernel.org
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Solar Designer <solar@openwall.com>
      Cc: "Srivatsa S. Bhat" <srivatsa@csail.mit.edu>
      Cc: Anthony Liguori <aliguori@amazon.com>
      Cc: Yang Yingliang <yangyingliang@huawei.com>
      Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Cc: Jiri Slaby <jirislaby@kernel.org>
      Signed-off-by: default avatarYunhai Zhang <zhangyunhai@nsfocus.com>
      Link: https://lore.kernel.org/r/9fb43895-ca91-9b07-ebfd-808cf854ca95@nsfocus.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8c19b606
    • Adam Ford's avatar
      omapfb: dss: Fix max fclk divider for omap36xx · 2780c5e9
      Adam Ford authored
      commit 254503a2 upstream.
      
      The drm/omap driver was fixed to correct an issue where using a
      divider of 32 breaks the DSS despite the TRM stating 32 is a valid
      number.  Through experimentation, it appears that 31 works, and
      it is consistent with the value used by the drm/omap driver.
      
      This patch fixes the divider for fbdev driver instead of the drm.
      
      Fixes: f76ee892 ("omapfb: copy omapdss & displays for omapfb")
      Cc: <stable@vger.kernel.org> #4.5+
      Signed-off-by: default avatarAdam Ford <aford173@gmail.com>
      Reviewed-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Dave Airlie <airlied@gmail.com>
      Cc: Rob Clark <robdclark@gmail.com>
      [b.zolnierkie: mark patch as applicable to stable 4.5+ (was 4.9+)]
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200630182636.439015-1-aford173@gmail.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2780c5e9
    • Peilin Ye's avatar
      Bluetooth: Prevent out-of-bounds read in hci_inquiry_result_with_rssi_evt() · df6f7185
      Peilin Ye authored
      commit 629b49c8 upstream.
      
      Check `num_rsp` before using it as for-loop counter. Add `unlock` label.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarPeilin Ye <yepeilin.cs@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      df6f7185
    • Peilin Ye's avatar
      Bluetooth: Prevent out-of-bounds read in hci_inquiry_result_evt() · 855a93a7
      Peilin Ye authored
      commit 75bbd2ea upstream.
      
      Check `num_rsp` before using it as for-loop counter.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarPeilin Ye <yepeilin.cs@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      855a93a7
    • Peilin Ye's avatar
      Bluetooth: Fix slab-out-of-bounds read in hci_extended_inquiry_result_evt() · aea77913
      Peilin Ye authored
      commit 51c19bf3 upstream.
      
      Check upon `num_rsp` is insufficient. A malformed event packet with a
      large `num_rsp` number makes hci_extended_inquiry_result_evt() go out
      of bounds. Fix it.
      
      This patch fixes the following syzbot bug:
      
          https://syzkaller.appspot.com/bug?id=4bf11aa05c4ca51ce0df86e500fce486552dc8d2
      
      Reported-by: syzbot+d8489a79b781849b9c46@syzkaller.appspotmail.com
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarPeilin Ye <yepeilin.cs@gmail.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aea77913
    • Takashi Iwai's avatar
      ALSA: seq: oss: Serialize ioctls · 5a48144e
      Takashi Iwai authored
      commit 80982c7e upstream.
      
      Some ioctls via OSS sequencer API may race and lead to UAF when the
      port create and delete are performed concurrently, as spotted by a
      couple of syzkaller cases.  This patch is an attempt to address it by
      serializing the ioctls with the existing register_mutex.
      
      Basically OSS sequencer API is an obsoleted interface and was designed
      without much consideration of the concurrency.  There are very few
      applications with it, and the concurrent performance isn't asked,
      hence this "big hammer" approach should be good enough.
      
      Reported-by: syzbot+1a54a94bd32716796edd@syzkaller.appspotmail.com
      Reported-by: syzbot+9d2abfef257f3e2d4713@syzkaller.appspotmail.com
      Suggested-by: default avatarHillf Danton <hdanton@sina.com>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20200804185815.2453-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5a48144e
    • Roi Dayan's avatar
      net/mlx5e: Don't support phys switch id if not in switchdev mode · 0216f889
      Roi Dayan authored
      Support for phys switch id ndo added for representors and if
      we do not have representors there is no need to support it.
      Since each port return different switch id supporting this
      block support for creating bond over PFs and attaching to bridge
      in legacy mode.
      
      This bug doesn't exist upstream as the code got refactored and the
      netdev api is totally different.
      
      Fixes: cb67b832 ("net/mlx5e: Introduce SRIOV VF representors")
      Signed-off-by: default avatarRoi Dayan <roid@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0216f889
    • Erik Ekman's avatar
      USB: serial: qcserial: add EM7305 QDL product ID · 487862fd
      Erik Ekman authored
      commit d2a4309c upstream.
      
      When running qmi-firmware-update on the Sierra Wireless EM7305 in a Toshiba
      laptop, it changed product ID to 0x9062 when entering QDL mode:
      
      usb 2-4: new high-speed USB device number 78 using xhci_hcd
      usb 2-4: New USB device found, idVendor=1199, idProduct=9062, bcdDevice= 0.00
      usb 2-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
      usb 2-4: Product: EM7305
      usb 2-4: Manufacturer: Sierra Wireless, Incorporated
      
      The upgrade could complete after running
       # echo 1199 9062 > /sys/bus/usb-serial/drivers/qcserial/new_id
      
      qcserial 2-4:1.0: Qualcomm USB modem converter detected
      usb 2-4: Qualcomm USB modem converter now attached to ttyUSB0
      Signed-off-by: default avatarErik Ekman <erik@kryo.se>
      Link: https://lore.kernel.org/r/20200717185118.3640219-1-erik@kryo.se
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      487862fd
    • Jiang Ying's avatar
      ext4: fix direct I/O read error · c8e44688
      Jiang Ying authored
      This patch is used to fix ext4 direct I/O read error when
      the read size is not aligned with block size.
      
      Then, I will use a test to explain the error.
      
      (1) Make a file that is not aligned with block size:
      	$dd if=/dev/zero of=./test.jar bs=1000 count=3
      
      (2) I wrote a source file named "direct_io_read_file.c" as following:
      
      	#include <stdio.h>
      	#include <stdlib.h>
      	#include <unistd.h>
      	#include <sys/file.h>
      	#include <sys/types.h>
      	#include <sys/stat.h>
      	#include <string.h>
      	#define BUF_SIZE 1024
      
      	int main()
      	{
      		int fd;
      		int ret;
      
      		unsigned char *buf;
      		ret = posix_memalign((void **)&buf, 512, BUF_SIZE);
      		if (ret) {
      			perror("posix_memalign failed");
      			exit(1);
      		}
      		fd = open("./test.jar", O_RDONLY | O_DIRECT, 0755);
      		if (fd < 0){
      			perror("open ./test.jar failed");
      			exit(1);
      		}
      
      		do {
      			ret = read(fd, buf, BUF_SIZE);
      			printf("ret=%d\n",ret);
      			if (ret < 0) {
      				perror("write test.jar failed");
      			}
      		} while (ret > 0);
      
      		free(buf);
      		close(fd);
      	}
      
      (3) Compile the source file:
      	$gcc direct_io_read_file.c -D_GNU_SOURCE
      
      (4) Run the test program:
      	$./a.out
      
      	The result is as following:
      	ret=1024
      	ret=1024
      	ret=952
      	ret=-1
      	write test.jar failed: Invalid argument.
      
      I have tested this program on XFS filesystem, XFS does not have
      this problem, because XFS use iomap_dio_rw() to do direct I/O
      read. And the comparing between read offset and file size is done
      in iomap_dio_rw(), the code is as following:
      
      	if (pos < size) {
      		retval = filemap_write_and_wait_range(mapping, pos,
      				pos + iov_length(iov, nr_segs) - 1);
      
      		if (!retval) {
      			retval = mapping->a_ops->direct_IO(READ, iocb,
      						iov, pos, nr_segs);
      		}
      		...
      	}
      
      ...only when "pos < size", direct I/O can be done, or 0 will be return.
      
      I have tested the fix patch on Ext4, it is up to the mustard of
      EINVAL in man2(read) as following:
      	#include <unistd.h>
      	ssize_t read(int fd, void *buf, size_t count);
      
      	EINVAL
      		fd is attached to an object which is unsuitable for reading;
      		or the file was opened with the O_DIRECT flag, and either the
      		address specified in buf, the value specified in count, or the
      		current file offset is not suitably aligned.
      
      So I think this patch can be applied to fix ext4 direct I/O error.
      
      However Ext4 introduces direct I/O read using iomap infrastructure
      on kernel 5.5, the patch is commit <b1b4705d>
      ("ext4: introduce direct I/O read using iomap infrastructure"),
      then Ext4 will be the same as XFS, they all use iomap_dio_rw() to do direct
      I/O read. So this problem does not exist on kernel 5.5 for Ext4.
      
      >From above description, we can see this problem exists on all the kernel
      versions between kernel 3.14 and kernel 5.4. It will cause the Applications
      to fail to read. For example, when the search service downloads a new full
      index file, the search engine is loading the previous index file and is
      processing the search request, it can not use buffer io that may squeeze
      the previous index file in use from pagecache, so the serch service must
      use direct I/O read.
      
      Please apply this patch on these kernel versions, or please use the method
      on kernel 5.5 to fix this problem.
      
      Fixes: 9fe55eea ("Fix race when checking i_size on direct i/o read")
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Reviewed-by: default avatarWang Long <wanglong19@meituan.com>
      Signed-off-by: default avatarJiang Ying <jiangying8582@126.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c8e44688
    • Linus Torvalds's avatar
      random32: move the pseudo-random 32-bit definitions to prandom.h · 82461648
      Linus Torvalds authored
      commit c0842fbc upstream.
      
      The addition of percpu.h to the list of includes in random.h revealed
      some circular dependencies on arm64 and possibly other platforms.  This
      include was added solely for the pseudo-random definitions, which have
      nothing to do with the rest of the definitions in this file but are
      still there for legacy reasons.
      
      This patch moves the pseudo-random parts to linux/prandom.h and the
      percpu.h include with it, which is now guarded by _LINUX_PRANDOM_H and
      protected against recursive inclusion.
      
      A further cleanup step would be to remove this from <linux/random.h>
      entirely, and make people who use the prandom infrastructure include
      just the new header file.  That's a bit of a churn patch, but grepping
      for "prandom_" and "next_pseudo_random32" "struct rnd_state" should
      catch most users.
      
      But it turns out that that nice cleanup step is fairly painful, because
      a _lot_ of code currently seems to depend on the implicit include of
      <linux/random.h>, which can currently come in a lot of ways, including
      such fairly core headfers as <linux/net.h>.
      
      So the "nice cleanup" part may or may never happen.
      
      Fixes: 1c9df907 ("random: fix circular include dependency on arm64 after addition of percpu.h")
      Tested-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Acked-by: default avatarWilly Tarreau <w@1wt.eu>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      82461648
    • Linus Torvalds's avatar
      random32: remove net_rand_state from the latent entropy gcc plugin · 8ce7dd3f
      Linus Torvalds authored
      commit 83bdc727 upstream.
      
      It turns out that the plugin right now ends up being really unhappy
      about the change from 'static' to 'extern' storage that happened in
      commit f227e3ec ("random32: update the net random state on interrupt
      and activity").
      
      This is probably a trivial fix for the latent_entropy plugin, but for
      now, just remove net_rand_state from the list of things the plugin
      worries about.
      Reported-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Cc: Emese Revfy <re.emese@gmail.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Willy Tarreau <w@1wt.eu>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8ce7dd3f
    • Willy Tarreau's avatar
      random: fix circular include dependency on arm64 after addition of percpu.h · 746fe496
      Willy Tarreau authored
      commit 1c9df907 upstream.
      
      Daniel Díaz and Kees Cook independently reported that commit
      f227e3ec ("random32: update the net random state on interrupt and
      activity") broke arm64 due to a circular dependency on include files
      since the addition of percpu.h in random.h.
      
      The correct fix would definitely be to move all the prandom32 stuff out
      of random.h but for backporting, a smaller solution is preferred.
      
      This one replaces linux/percpu.h with asm/percpu.h, and this fixes the
      problem on x86_64, arm64, arm, and mips.  Note that moving percpu.h
      around didn't change anything and that removing it entirely broke
      differently.  When backporting, such options might still be considered
      if this patch fails to help.
      
      [ It turns out that an alternate fix seems to be to just remove the
        troublesome <asm/pointer_auth.h> remove from the arm64 <asm/smp.h>
        that causes the circular dependency.
      
        But we might as well do the whole belt-and-suspenders thing, and
        minimize inclusion in <linux/random.h> too. Either will fix the
        problem, and both are good changes.   - Linus ]
      Reported-by: default avatarDaniel Díaz <daniel.diaz@linaro.org>
      Reported-by: default avatarKees Cook <keescook@chromium.org>
      Tested-by: default avatarMarc Zyngier <maz@kernel.org>
      Fixes: f227e3ec
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      746fe496
    • Grygorii Strashko's avatar
      ARM: percpu.h: fix build error · 473b095f
      Grygorii Strashko authored
      commit aa54ea90 upstream.
      
      Fix build error for the case:
        defined(CONFIG_SMP) && !defined(CONFIG_CPU_V6)
      
      config: keystone_defconfig
      
        CC      arch/arm/kernel/signal.o
        In file included from ../include/linux/random.h:14,
                          from ../arch/arm/kernel/signal.c:8:
        ../arch/arm/include/asm/percpu.h: In function ‘__my_cpu_offset’:
        ../arch/arm/include/asm/percpu.h:29:34: error: ‘current_stack_pointer’ undeclared (first use in this function); did you mean ‘user_stack_pointer’?
            : "Q" (*(const unsigned long *)current_stack_pointer));
                                           ^~~~~~~~~~~~~~~~~~~~~
                                           user_stack_pointer
      
      Fixes: f227e3ec ("random32: update the net random state on interrupt and activity")
      Signed-off-by: default avatarGrygorii Strashko <grygorii.strashko@ti.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      473b095f
    • Willy Tarreau's avatar
      random32: update the net random state on interrupt and activity · 5aa78397
      Willy Tarreau authored
      commit f227e3ec upstream.
      
      This modifies the first 32 bits out of the 128 bits of a random CPU's
      net_rand_state on interrupt or CPU activity to complicate remote
      observations that could lead to guessing the network RNG's internal
      state.
      
      Note that depending on some network devices' interrupt rate moderation
      or binding, this re-seeding might happen on every packet or even almost
      never.
      
      In addition, with NOHZ some CPUs might not even get timer interrupts,
      leaving their local state rarely updated, while they are running
      networked processes making use of the random state.  For this reason, we
      also perform this update in update_process_times() in order to at least
      update the state when there is user or system activity, since it's the
      only case we care about.
      Reported-by: default avatarAmit Klein <aksecurity@gmail.com>
      Suggested-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5aa78397
    • Thomas Gleixner's avatar
      x86/i8259: Use printk_deferred() to prevent deadlock · dfd6b6e8
      Thomas Gleixner authored
      commit bdd65589 upstream.
      
      0day reported a possible circular locking dependency:
      
      Chain exists of:
        &irq_desc_lock_class --> console_owner --> &port_lock_key
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(&port_lock_key);
                                     lock(console_owner);
                                     lock(&port_lock_key);
        lock(&irq_desc_lock_class);
      
      The reason for this is a printk() in the i8259 interrupt chip driver
      which is invoked with the irq descriptor lock held, which reverses the
      lock operations vs. printk() from arbitrary contexts.
      
      Switch the printk() to printk_deferred() to avoid that.
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Cc: stable@vger.kernel.org
      Link: https://lore.kernel.org/r/87365abt2v.fsf@nanos.tec.linutronix.deSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dfd6b6e8
    • Wanpeng Li's avatar
      KVM: LAPIC: Prevent setting the tscdeadline timer if the lapic is hw disabled · 575350ea
      Wanpeng Li authored
      commit d2286ba7 upstream.
      
      Prevent setting the tscdeadline timer if the lapic is hw disabled.
      
      Fixes: bce87cce (KVM: x86: consolidate different ways to test for in-kernel LAPIC)
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarWanpeng Li <wanpengli@tencent.com>
      Message-Id: <1596165141-28874-1-git-send-email-wanpengli@tencent.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      575350ea
    • Andrea Righi's avatar
      xen-netfront: fix potential deadlock in xennet_remove() · 6015a692
      Andrea Righi authored
      [ Upstream commit c2c63310 ]
      
      There's a potential race in xennet_remove(); this is what the driver is
      doing upon unregistering a network device:
      
        1. state = read bus state
        2. if state is not "Closed":
        3.    request to set state to "Closing"
        4.    wait for state to be set to "Closing"
        5.    request to set state to "Closed"
        6.    wait for state to be set to "Closed"
      
      If the state changes to "Closed" immediately after step 1 we are stuck
      forever in step 4, because the state will never go back from "Closed" to
      "Closing".
      
      Make sure to check also for state == "Closed" in step 4 to prevent the
      deadlock.
      
      Also add a 5 sec timeout any time we wait for the bus state to change,
      to avoid getting stuck forever in wait_event().
      Signed-off-by: default avatarAndrea Righi <andrea.righi@canonical.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      6015a692
    • Raviteja Narayanam's avatar
      Revert "i2c: cadence: Fix the hold bit setting" · 0102ed8c
      Raviteja Narayanam authored
      [ Upstream commit 0db9254d ]
      
      This reverts commit d358def7.
      
      There are two issues with "i2c: cadence: Fix the hold bit setting" commit.
      
      1. In case of combined message request from user space, when the HOLD
      bit is cleared in cdns_i2c_mrecv function, a STOP condition is sent
      on the bus even before the last message is started. This is because when
      the HOLD bit is cleared, the FIFOS are empty and there is no pending
      transfer. The STOP condition should occur only after the last message
      is completed.
      
      2. The code added by the commit is redundant. Driver is handling the
      setting/clearing of HOLD bit in right way before the commit.
      
      The setting of HOLD bit based on 'bus_hold_flag' is taken care in
      cdns_i2c_master_xfer function even before cdns_i2c_msend/cdns_i2c_recv
      functions.
      
      The clearing of HOLD bit is taken care at the end of cdns_i2c_msend and
      cdns_i2c_recv functions based on bus_hold_flag and byte count.
      Since clearing of HOLD bit is done after the slave address is written to
      the register (writing to address register triggers the message transfer),
      it is ensured that STOP condition occurs at the right time after
      completion of the pending transfer (last message).
      Signed-off-by: default avatarRaviteja Narayanam <raviteja.narayanam@xilinx.com>
      Acked-by: default avatarMichal Simek <michal.simek@xilinx.com>
      Signed-off-by: default avatarWolfram Sang <wsa@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      0102ed8c
    • Yoshihiro Shimoda's avatar
      net: ethernet: ravb: exit if re-initialization fails in tx timeout · 94791d92
      Yoshihiro Shimoda authored
      [ Upstream commit 015c5d5e ]
      
      According to the report of [1], this driver is possible to cause
      the following error in ravb_tx_timeout_work().
      
      ravb e6800000.ethernet ethernet: failed to switch device to config mode
      
      This error means that the hardware could not change the state
      from "Operation" to "Configuration" while some tx and/or rx queue
      are operating. After that, ravb_config() in ravb_dmac_init() will fail,
      and then any descriptors will be not allocaled anymore so that NULL
      pointer dereference happens after that on ravb_start_xmit().
      
      To fix the issue, the ravb_tx_timeout_work() should check
      the return values of ravb_stop_dma() and ravb_dmac_init().
      If ravb_stop_dma() fails, ravb_tx_timeout_work() re-enables TX and RX
      and just exits. If ravb_dmac_init() fails, just exits.
      
      [1]
      https://lore.kernel.org/linux-renesas-soc/20200518045452.2390-1-dirk.behme@de.bosch.com/Reported-by: default avatarDirk Behme <dirk.behme@de.bosch.com>
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Reviewed-by: default avatarSergei Shtylyov <sergei.shtylyov@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      94791d92
    • Liam Beguin's avatar
      parisc: add support for cmpxchg on u8 pointers · 78c4268b
      Liam Beguin authored
      [ Upstream commit b344d6a8 ]
      
      The kernel test bot reported[1] that using set_mask_bits on a u8 causes
      the following issue on parisc:
      
      	hppa-linux-ld: drivers/phy/ti/phy-tusb1210.o: in function `tusb1210_probe':
      	>> (.text+0x2f4): undefined reference to `__cmpxchg_called_with_bad_pointer'
      	>> hppa-linux-ld: (.text+0x324): undefined reference to `__cmpxchg_called_with_bad_pointer'
      	hppa-linux-ld: (.text+0x354): undefined reference to `__cmpxchg_called_with_bad_pointer'
      
      Add support for cmpxchg on u8 pointers.
      
      [1] https://lore.kernel.org/patchwork/patch/1272617/#1468946Reported-by: default avatarkernel test robot <lkp@intel.com>
      Signed-off-by: default avatarLiam Beguin <liambeguin@gmail.com>
      Tested-by: default avatarDave Anglin <dave.anglin@bell.net>
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      78c4268b
    • Navid Emamdoost's avatar
      nfc: s3fwrn5: add missing release on skb in s3fwrn5_recv_frame · 8be68d5c
      Navid Emamdoost authored
      [ Upstream commit 1e8fd3a9 ]
      
      The implementation of s3fwrn5_recv_frame() is supposed to consume skb on
      all execution paths. Release skb before returning -ENODEV.
      Signed-off-by: default avatarNavid Emamdoost <navid.emamdoost@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8be68d5c
    • Laurence Oberman's avatar
      qed: Disable "MFW indication via attention" SPAM every 5 minutes · 357f6ddc
      Laurence Oberman authored
      [ Upstream commit 1d61e218 ]
      
      This is likely firmware causing this but its starting to annoy customers.
      Change the message level to verbose to prevent the spam.
      Note that this seems to only show up with ISCSI enabled on the HBA via the
      qedi driver.
      Signed-off-by: default avatarLaurence Oberman <loberman@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      357f6ddc