1. 15 2月, 2019 40 次提交
    • L
      Revert "exec: load_script: don't blindly truncate shebang string" · c2109f05
      Linus Torvalds 提交于
      commit cb5b020a8d38f77209d0472a0fea755299a8ec78 upstream.
      
      This reverts commit 8099b047ecc431518b9bb6bdbba3549bbecdc343.
      
      It turns out that people do actually depend on the shebang string being
      truncated, and on the fact that an interpreter (like perl) will often
      just re-interpret it entirely to get the full argument list.
      Reported-by: NSamuel Dionne-Riel <samuel@dionne-riel.com>
      Acked-by: NKees Cook <keescook@chromium.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c2109f05
    • G
      Linux 4.19.22 · 6f8c14ee
      Greg Kroah-Hartman 提交于
      6f8c14ee
    • C
      svcrdma: Remove max_sge check at connect time · 9b65b18f
      Chuck Lever 提交于
      commit e248aa7be86e8179f20ac0931774ecd746f3f5bf upstream.
      
      Two and a half years ago, the client was changed to use gathered
      Send for larger inline messages, in commit 655fec69 ("xprtrdma:
      Use gathered Send for large inline messages"). Several fixes were
      required because there are a few in-kernel device drivers whose
      max_sge is 3, and these were broken by the change.
      
      Apparently my memory is going, because some time later, I submitted
      commit 25fd86ec ("svcrdma: Don't overrun the SGE array in
      svc_rdma_send_ctxt"), and after that, commit f3c1fd0ee294 ("svcrdma:
      Reduce max_send_sges"). These too incorrectly assumed in-kernel
      device drivers would have more than a few Send SGEs available.
      
      The fix for the server side is not the same. This is because the
      fundamental problem on the server is that, whether or not the client
      has provisioned a chunk for the RPC reply, the server must squeeze
      even the most complex RPC replies into a single RDMA Send. Failing
      in the send path because of Send SGE exhaustion should never be an
      option.
      
      Therefore, instead of failing when the send path runs out of SGEs,
      switch to using a bounce buffer mechanism to handle RPC replies that
      are too complex for the device to send directly. That allows us to
      remove the max_sge check to enable drivers with small max_sge to
      work again.
      Reported-by: NDon Dutile <ddutile@redhat.com>
      Fixes: 25fd86ec ("svcrdma: Don't overrun the SGE array in ...")
      Cc: stable@vger.kernel.org
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9b65b18f
    • C
      svcrdma: Reduce max_send_sges · 4d376ab8
      Chuck Lever 提交于
      commit f3c1fd0ee294abd4367dfa72d89f016c682202f0 upstream.
      
      There's no need to request a large number of send SGEs because the
      inline threshold already constrains the number of SGEs per Send.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Reviewed-by: NSagi Grimberg <sagi@grimberg.me>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      Cc: Don Dutile <ddutile@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4d376ab8
    • S
      batman-adv: Force mac header to start of data on xmit · 4dd911f1
      Sven Eckelmann 提交于
      commit 9114daa825fc3f335f9bea3313ce667090187280 upstream.
      
      The caller of ndo_start_xmit may not already have called
      skb_reset_mac_header. The returned value of skb_mac_header/eth_hdr
      therefore can be in the wrong position and even outside the current skbuff.
      This for example happens when the user binds to the device using a
      PF_PACKET-SOCK_RAW with enabled qdisc-bypass:
      
        int opt = 4;
        setsockopt(sock, SOL_PACKET, PACKET_QDISC_BYPASS, &opt, sizeof(opt));
      
      Since eth_hdr is used all over the codebase, the batadv_interface_tx
      function must always take care of resetting it.
      
      Fixes: c6c8fea2 ("net: Add batman-adv meshing protocol")
      Reported-by: syzbot+9d7405c7faa390e60b4e@syzkaller.appspotmail.com
      Reported-by: syzbot+7d20bc3f1ddddc0f9079@syzkaller.appspotmail.com
      Signed-off-by: NSven Eckelmann <sven@narfation.org>
      Signed-off-by: NSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4dd911f1
    • S
      batman-adv: Avoid WARN on net_device without parent in netns · a2122230
      Sven Eckelmann 提交于
      commit 955d3411a17f590364238bd0d3329b61f20c1cd2 upstream.
      
      It is not allowed to use WARN* helpers on potential incorrect input from
      the user or transient problems because systems configured as panic_on_warn
      will reboot due to such a problem.
      
      A NULL return value of __dev_get_by_index can be caused by various problems
      which can either be related to the system configuration or problems
      (incorrectly returned network namespaces) in other (virtual) net_device
      drivers. batman-adv should not cause a (harmful) WARN in this situation and
      instead only report it via a simple message.
      
      Fixes: b7eddd0b ("batman-adv: prevent using any virtual device created on batman-adv as hard-interface")
      Reported-by: syzbot+c764de0fcfadca9a8595@syzkaller.appspotmail.com
      Reported-by: NDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: NSven Eckelmann <sven@narfation.org>
      Signed-off-by: NSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a2122230
    • F
      xfrm: refine validation of template and selector families · 9d84284c
      Florian Westphal 提交于
      commit 35e6103861a3a970de6c84688c6e7a1f65b164ca upstream.
      
      The check assumes that in transport mode, the first templates family
      must match the address family of the policy selector.
      
      Syzkaller managed to build a template using MODE_ROUTEOPTIMIZATION,
      with ipv4-in-ipv6 chain, leading to following splat:
      
      BUG: KASAN: stack-out-of-bounds in xfrm_state_find+0x1db/0x1854
      Read of size 4 at addr ffff888063e57aa0 by task a.out/2050
       xfrm_state_find+0x1db/0x1854
       xfrm_tmpl_resolve+0x100/0x1d0
       xfrm_resolve_and_create_bundle+0x108/0x1000 [..]
      
      Problem is that addresses point into flowi4 struct, but xfrm_state_find
      treats them as being ipv6 because it uses templ->encap_family is used
      (AF_INET6 in case of reproducer) rather than family (AF_INET).
      
      This patch inverts the logic: Enforce 'template family must match
      selector' EXCEPT for tunnel and BEET mode.
      
      In BEET and Tunnel mode, xfrm_tmpl_resolve_one will have remote/local
      address pointers changed to point at the addresses found in the template,
      rather than the flowi ones, so no oob read will occur.
      
      Reported-by: 3ntr0py1337@gmail.com
      Reported-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9d84284c
    • I
      libceph: avoid KEEPALIVE_PENDING races in ceph_con_keepalive() · f7fb58a7
      Ilya Dryomov 提交于
      commit 4aac9228d16458cedcfd90c7fb37211cf3653ac3 upstream.
      
      con_fault() can transition the connection into STANDBY right after
      ceph_con_keepalive() clears STANDBY in clear_standby():
      
          libceph user thread               ceph-msgr worker
      
      ceph_con_keepalive()
        mutex_lock(&con->mutex)
        clear_standby(con)
        mutex_unlock(&con->mutex)
                                      mutex_lock(&con->mutex)
                                      con_fault()
                                        ...
                                        if KEEPALIVE_PENDING isn't set
                                          set state to STANDBY
                                        ...
                                      mutex_unlock(&con->mutex)
        set KEEPALIVE_PENDING
        set WRITE_PENDING
      
      This triggers warnings in clear_standby() when either ceph_con_send()
      or ceph_con_keepalive() get to clearing STANDBY next time.
      
      I don't see a reason to condition queue_con() call on the previous
      value of KEEPALIVE_PENDING, so move the setting of KEEPALIVE_PENDING
      into the critical section -- unlike WRITE_PENDING, KEEPALIVE_PENDING
      could have been a non-atomic flag.
      
      Reported-by: syzbot+acdeb633f6211ccdf886@syzkaller.appspotmail.com
      Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
      Tested-by: NMyungho Jung <mhjungk@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f7fb58a7
    • T
      Revert "ext4: use ext4_write_inode() when fsyncing w/o a journal" · 28f49e76
      Theodore Ts'o 提交于
      commit 8fdd60f2ae3682caf2a7258626abc21eb4711892 upstream.
      
      This reverts commit ad211f3e94b314a910d4af03178a0b52a7d1ee0a.
      
      As Jan Kara pointed out, this change was unsafe since it means we lose
      the call to sync_mapping_buffers() in the nojournal case.  The
      original point of the commit was avoid taking the inode mutex (since
      it causes a lockdep warning in generic/113); but we need the mutex in
      order to call sync_mapping_buffers().
      
      The real fix to this problem was discussed here:
      
      https://lore.kernel.org/lkml/20181025150540.259281-4-bvanassche@acm.org
      
      The proposed patch was to fix a syzbot complaint, but the problem can
      also demonstrated via "kvm-xfstests -c nojournal generic/113".
      Multiple solutions were discused in the e-mail thread, but none have
      landed in the kernel as of this writing.  Anyway, commit
      ad211f3e94b314 is absolutely the wrong way to suppress the lockdep, so
      revert it.
      
      Fixes: ad211f3e94b314a910d4af03178a0b52a7d1ee0a ("ext4: use ext4_write_inode() when fsyncing w/o a journal")
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      Reported: Jan Kara <jack@suse.cz>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      28f49e76
    • B
      xfrm: Make set-mark default behavior backward compatible · 8b8f7b04
      Benedict Wong 提交于
      commit e2612cd496e7b465711d219ea6118893d7253f52 upstream.
      
      Fixes 9b42c1f1, which changed the default route lookup behavior for
      tunnel mode SAs in the outbound direction to use the skb mark, whereas
      previously mark=0 was used if the output mark was unspecified. In
      mark-based routing schemes such as Android’s, this change in default
      behavior causes routing loops or lookup failures.
      
      This patch restores the default behavior of using a 0 mark while still
      incorporating the skb mark if the SET_MARK (and SET_MARK_MASK) is
      specified.
      
      Tested with additions to Android's kernel unit test suite:
      https://android-review.googlesource.com/c/kernel/tests/+/860150
      
      Fixes: 9b42c1f1 ("xfrm: Extend the output_mark to support input direction and masking")
      Signed-off-by: NBenedict Wong <benedictwong@google.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8b8f7b04
    • B
      SUNRPC: Always drop the XPRT_LOCK on XPRT_CLOSE_WAIT · 2440f3ce
      Benjamin Coddington 提交于
      This patch is only appropriate for stable kernels v4.16 - v4.19
      
      Since commit 9b30889c ("SUNRPC: Ensure we always close the socket after
      a connection shuts down"), and until commit c544577daddb ("SUNRPC: Clean up
      transport write space handling"), it is possible for the NFS client to spin
      in the following tight loop:
      
      269.964083: rpc_task_run_action: task:43@0 flags=5a81 state=0005 status=0 action=call_bind [sunrpc]
      269.964083: rpc_task_run_action: task:43@0 flags=5a81 state=0005 status=0 action=call_connect [sunrpc]
      269.964083: rpc_task_run_action: task:43@0 flags=5a81 state=0005 status=0 action=call_transmit [sunrpc]
      269.964085: xprt_transmit: peer=[10.0.1.82]:2049 xid=0x761d3f77 status=-32
      269.964085: rpc_task_run_action: task:43@0 flags=5a81 state=0005 status=-32 action=call_transmit_status [sunrpc]
      269.964085: rpc_task_run_action: task:43@0 flags=5a81 state=0005 status=-32 action=call_status [sunrpc]
      269.964085: rpc_call_status: task:43@0 status=-32
      
      The issue is that the path through call_transmit_status does not release
      the XPRT_LOCK when the transmit result is -EPIPE, so the socket cannot be
      properly shut down.
      
      The below commit fixed things up in mainline by unconditionally calling
      xprt_end_transmit() and releasing the XPRT_LOCK after every pass through
      call_transmit.  However, the entirety of this commit is not appropriate for
      stable kernels because its original inclusion was part of a series that
      modifies the sunrpc code to use a different queueing model.  As a result,
      there are machinations within this patch that are not needed for a stable
      fix and will not make sense without a larger backport of the mainline
      series.
      
      In this patch, we take the slightly modified bit of the mainline patch
      below, which is to release the XPRT_LOCK on transmission error should we
      detect that the transport is waiting to close.
      
      commit c544577daddb618c7dd5fa7fb98d6a41782f020e upstream
      Author: Trond Myklebust <trond.myklebust@hammerspace.com>
      Date:   Mon Sep 3 23:39:27 2018 -0400
      
          SUNRPC: Clean up transport write space handling
      
          Treat socket write space handling in the same way we now treat transport
          congestion: by denying the XPRT_LOCK until the transport signals that it
          has free buffer space.
      Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
      
      The original discussion of the problem is here:
      
          https://lore.kernel.org/linux-nfs/20181212135157.4489-1-dwysocha@redhat.com/T/#t
      
      This passes my usual cthon and xfstests on NFS as applied on v4.19 mainline.
      Reported-by: NDave Wysochanski <dwysocha@redhat.com>
      Suggested-by: NTrond Myklebust <trondmy@hammerspace.com>
      Signed-off-by: NBenjamin Coddington <bcodding@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2440f3ce
    • T
      drm/vmwgfx: Return error code from vmw_execbuf_copy_fence_user · 8274c3d4
      Thomas Hellstrom 提交于
      commit 728354c005c36eaf44b6e5552372b67e60d17f56 upstream.
      
      The function was unconditionally returning 0, and a caller would have to
      rely on the returned fence pointer being NULL to detect errors. However,
      the function vmw_execbuf_copy_fence_user() would expect a non-zero error
      code in that case and would BUG otherwise.
      
      So make sure we return a proper non-zero error code if the fence pointer
      returned is NULL.
      
      Cc: <stable@vger.kernel.org>
      Fixes: ae2a1040: ("vmwgfx: Implement fence objects")
      Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: NDeepak Rawat <drawat@vmware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8274c3d4
    • T
      drm/vmwgfx: Fix setting of dma masks · d74ff5f6
      Thomas Hellstrom 提交于
      commit 4cbfa1e6c09e98450aab3240e5119b0ab2c9795b upstream.
      
      Previously we set only the dma mask and not the coherent mask. Fix that.
      Also, for clarity, make sure both are initially set to 64 bits.
      
      Cc: <stable@vger.kernel.org>
      Fixes: 0d00c488: ("drm/vmwgfx: Fix the driver for large dma addresses")
      Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: NDeepak Rawat <drawat@vmware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d74ff5f6
    • L
      drm/i915: always return something on DDI clock selection · c2a354ce
      Lucas De Marchi 提交于
      commit 2a121030d4ee3f84f60c6f415f9c44bffbcde81d upstream.
      
      Even if we don't have the correct clock and get a warning, we should not
      skip the return.
      
      v2: improve commit message (from Joonas)
      
      Fixes: 1fa11ee2 ("drm/i915/icl: start adding the TBT pll")
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Cc: <stable@vger.kernel.org> # v4.19+
      Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
      Reviewed-by: NMika Kahola <mika.kahola@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190125222444.19926-3-lucas.demarchi@intel.com
      (cherry picked from commit 7a61a6dec3dfb9f2e8c39a337580a3c3036c5cdf)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c2a354ce
    • G
      drm/amd/powerplay: Fix missing break in switch · b81afe37
      Gustavo A. R. Silva 提交于
      commit 2f10d823739680d2477ce34437e8a08a53117f40 upstream.
      
      Add missing break statement in order to prevent the code from falling
      through to the default case.
      
      The resoning for this is that pclk_vol_table is an automatic variable.
      So, it makes no sense to update it just before falling through to the
      default case and return -EINVAL.
      
      This bug was found thanks to the ongoing efforts to enabling
      -Wimplicit-fallthrough.
      
      Fixes: cd70f3d6 ("drm/amd/powerplay: PP/DAL interface changes for dynamic clock switch")
      Cc: stable@vger.kernel.org
      Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b81afe37
    • T
      drm/modes: Prevent division by zero htotal · 56d31786
      Tina Zhang 提交于
      commit a2fcd5c84f7a7825e028381b10182439067aa90d upstream.
      
      This patch prevents division by zero htotal.
      
      In a follow-up mail Tina writes:
      
      > > How did you manage to get here with htotal == 0? This needs backtraces (or if
      > > this is just about static checkers, a mention of that).
      > > -Daniel
      >
      > In GVT-g, we are trying to enable a virtual display w/o setting timings for a pipe
      > (a.k.a htotal=0), then we met the following kernel panic:
      >
      > [   32.832048] divide error: 0000 [#1] SMP PTI
      > [   32.833614] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.18.0-rc4-sriov+ #33
      > [   32.834438] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.10.1-0-g8891697-dirty-20180511_165818-tinazhang-linux-1 04/01/2014
      > [   32.835901] RIP: 0010:drm_mode_hsync+0x1e/0x40
      > [   32.836004] Code: 31 c0 c3 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 8b 87 d8 00 00 00 85 c0 75 22 8b 4f 68 85 c9 78 1b 69 47 58 e8 03 00 00 99 <f7> f9 b9 d3 4d 62 10 05 f4 01 00 00 f7 e1 89 d0 c1 e8 06 f3 c3 66
      > [   32.836004] RSP: 0000:ffffc900000ebb90 EFLAGS: 00010206
      > [   32.836004] RAX: 0000000000000000 RBX: ffff88001c67c8a0 RCX: 0000000000000000
      > [   32.836004] RDX: 0000000000000000 RSI: ffff88001c67c000 RDI: ffff88001c67c8a0
      > [   32.836004] RBP: ffff88001c7d03a0 R08: ffff88001c67c8a0 R09: ffff88001c7d0330
      > [   32.836004] R10: ffffffff822c3a98 R11: 0000000000000001 R12: ffff88001c67c000
      > [   32.836004] R13: ffff88001c7d0370 R14: ffffffff8207eb78 R15: ffff88001c67c800
      > [   32.836004] FS:  0000000000000000(0000) GS:ffff88001da00000(0000) knlGS:0000000000000000
      > [   32.836004] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      > [   32.836004] CR2: 0000000000000000 CR3: 000000000220a000 CR4: 00000000000006f0
      > [   32.836004] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      > [   32.836004] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      > [   32.836004] Call Trace:
      > [   32.836004]  intel_mode_from_pipe_config+0x72/0x90
      > [   32.836004]  intel_modeset_setup_hw_state+0x569/0xf90
      > [   32.836004]  intel_modeset_init+0x905/0x1db0
      > [   32.836004]  i915_driver_load+0xb8c/0x1120
      > [   32.836004]  i915_pci_probe+0x4d/0xb0
      > [   32.836004]  local_pci_probe+0x44/0xa0
      > [   32.836004]  ? pci_assign_irq+0x27/0x130
      > [   32.836004]  pci_device_probe+0x102/0x1c0
      > [   32.836004]  driver_probe_device+0x2b8/0x480
      > [   32.836004]  __driver_attach+0x109/0x110
      > [   32.836004]  ? driver_probe_device+0x480/0x480
      > [   32.836004]  bus_for_each_dev+0x67/0xc0
      > [   32.836004]  ? klist_add_tail+0x3b/0x70
      > [   32.836004]  bus_add_driver+0x1e8/0x260
      > [   32.836004]  driver_register+0x5b/0xe0
      > [   32.836004]  ? mipi_dsi_bus_init+0x11/0x11
      > [   32.836004]  do_one_initcall+0x4d/0x1eb
      > [   32.836004]  kernel_init_freeable+0x197/0x237
      > [   32.836004]  ? rest_init+0xd0/0xd0
      > [   32.836004]  kernel_init+0xa/0x110
      > [   32.836004]  ret_from_fork+0x35/0x40
      > [   32.836004] Modules linked in:
      > [   32.859183] ---[ end trace 525608b0ed0e8665 ]---
      > [   32.859722] RIP: 0010:drm_mode_hsync+0x1e/0x40
      > [   32.860287] Code: 31 c0 c3 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 8b 87 d8 00 00 00 85 c0 75 22 8b 4f 68 85 c9 78 1b 69 47 58 e8 03 00 00 99 <f7> f9 b9 d3 4d 62 10 05 f4 01 00 00 f7 e1 89 d0 c1 e8 06 f3 c3 66
      > [   32.862680] RSP: 0000:ffffc900000ebb90 EFLAGS: 00010206
      > [   32.863309] RAX: 0000000000000000 RBX: ffff88001c67c8a0 RCX: 0000000000000000
      > [   32.864182] RDX: 0000000000000000 RSI: ffff88001c67c000 RDI: ffff88001c67c8a0
      > [   32.865206] RBP: ffff88001c7d03a0 R08: ffff88001c67c8a0 R09: ffff88001c7d0330
      > [   32.866359] R10: ffffffff822c3a98 R11: 0000000000000001 R12: ffff88001c67c000
      > [   32.867213] R13: ffff88001c7d0370 R14: ffffffff8207eb78 R15: ffff88001c67c800
      > [   32.868075] FS:  0000000000000000(0000) GS:ffff88001da00000(0000) knlGS:0000000000000000
      > [   32.868983] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      > [   32.869659] CR2: 0000000000000000 CR3: 000000000220a000 CR4: 00000000000006f0
      > [   32.870599] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      > [   32.871598] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      > [   32.872549] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
      >
      > Since drm_mode_hsync() has the logic to check mode->htotal, I just extend it to cover the case htotal==0.
      Signed-off-by: NTina Zhang <tina.zhang@intel.com>
      Cc: Adam Jackson <ajax@redhat.com>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      [danvet: Add additional explanations + cc: stable.]
      Cc: stable@vger.kernel.org
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/1548228539-3061-1-git-send-email-tina.zhang@intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      56d31786
    • F
      mac80211: ensure that mgmt tx skbs have tailroom for encryption · a4c77aac
      Felix Fietkau 提交于
      commit 9d0f50b80222dc273e67e4e14410fcfa4130a90c upstream.
      
      Some drivers use IEEE80211_KEY_FLAG_SW_MGMT_TX to indicate that management
      frames need to be software encrypted. Since normal data packets are still
      encrypted by the hardware, crypto_tx_tailroom_needed_cnt gets decremented
      after key upload to hw. This can lead to passing skbs to ccmp_encrypt_skb,
      which don't have the necessary tailroom for software encryption.
      
      Change the code to add tailroom for encrypted management packets, even if
      crypto_tx_tailroom_needed_cnt is 0.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NFelix Fietkau <nbd@nbd.name>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a4c77aac
    • V
      mic: vop: Fix use-after-free on remove · 1ce0fceb
      Vincent Whitchurch 提交于
      commit 70ed7148dadb812f2f7c9927e98ef3cf4869dfa9 upstream.
      
      KASAN detects a use-after-free when vop devices are removed.
      
      This problem was introduced by commit 0063e8bb ("virtio_vop:
      don't kfree device on register failure").  That patch moved the freeing
      of the struct _vop_vdev to the release function, but failed to ensure
      that vop holds a reference to the device when it doesn't want it to go
      away.  A kfree() was replaced with a put_device() in the unregistration
      path, but the last reference to the device is already dropped in
      unregister_virtio_device() so the struct is freed before vop is done
      with it.
      
      Fix it by holding a reference until cleanup is done.  This is similar to
      the fix in virtio_pci in commit 2989be09 ("virtio_pci: fix use
      after free on release").
      
       ==================================================================
       BUG: KASAN: use-after-free in vop_scan_devices+0xc6c/0xe50 [vop]
       Read of size 8 at addr ffff88800da18580 by task kworker/0:1/12
      
       CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.0.0-rc4+ #53
       Workqueue: events vop_hotplug_devices [vop]
       Call Trace:
        dump_stack+0x74/0xbb
        print_address_description+0x5d/0x2b0
        ? vop_scan_devices+0xc6c/0xe50 [vop]
        kasan_report+0x152/0x1aa
        ? vop_scan_devices+0xc6c/0xe50 [vop]
        ? vop_scan_devices+0xc6c/0xe50 [vop]
        vop_scan_devices+0xc6c/0xe50 [vop]
        ? vop_loopback_free_irq+0x160/0x160 [vop_loopback]
        process_one_work+0x7c0/0x14b0
        ? pwq_dec_nr_in_flight+0x2d0/0x2d0
        ? do_raw_spin_lock+0x120/0x280
        worker_thread+0x8f/0xbf0
        ? __kthread_parkme+0x78/0xf0
        ? process_one_work+0x14b0/0x14b0
        kthread+0x2ae/0x3a0
        ? kthread_park+0x120/0x120
        ret_from_fork+0x3a/0x50
      
       Allocated by task 12:
        kmem_cache_alloc_trace+0x13a/0x2a0
        vop_scan_devices+0x473/0xe50 [vop]
        process_one_work+0x7c0/0x14b0
        worker_thread+0x8f/0xbf0
        kthread+0x2ae/0x3a0
        ret_from_fork+0x3a/0x50
      
       Freed by task 12:
        kfree+0x104/0x310
        device_release+0x73/0x1d0
        kobject_put+0x14f/0x420
        unregister_virtio_device+0x32/0x50
        vop_scan_devices+0x19d/0xe50 [vop]
        process_one_work+0x7c0/0x14b0
        worker_thread+0x8f/0xbf0
        kthread+0x2ae/0x3a0
        ret_from_fork+0x3a/0x50
      
       The buggy address belongs to the object at ffff88800da18008
        which belongs to the cache kmalloc-2k of size 2048
       The buggy address is located 1400 bytes inside of
        2048-byte region [ffff88800da18008, ffff88800da18808)
       The buggy address belongs to the page:
       page:ffffea0000368600 count:1 mapcount:0 mapping:ffff88801440dbc0 index:0x0 compound_mapcount: 0
       flags: 0x4000000000010200(slab|head)
       raw: 4000000000010200 ffffea0000378608 ffffea000037a008 ffff88801440dbc0
       raw: 0000000000000000 00000000000d000d 00000001ffffffff 0000000000000000
       page dumped because: kasan: bad access detected
      
       Memory state around the buggy address:
        ffff88800da18480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
        ffff88800da18500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       >ffff88800da18580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                          ^
        ffff88800da18600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
        ffff88800da18680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ==================================================================
      
      Fixes: 0063e8bb ("virtio_vop: don't kfree device on register failure")
      Signed-off-by: NVincent Whitchurch <vincent.whitchurch@axis.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1ce0fceb
    • A
      powerpc/radix: Fix kernel crash with mremap() · 49c473e1
      Aneesh Kumar K.V 提交于
      commit 579b9239c1f38665b21e8d0e6ee83ecc96dbd6bb upstream.
      
      With support for split pmd lock, we use pmd page pmd_huge_pte pointer
      to store the deposited page table. In those config when we move page
      tables we need to make sure we move the deposited page table to the
      correct pmd page. Otherwise this can result in crash when we withdraw
      of deposited page table because we can find the pmd_huge_pte NULL.
      
      eg:
      
        __split_huge_pmd+0x1070/0x1940
        __split_huge_pmd+0xe34/0x1940 (unreliable)
        vma_adjust_trans_huge+0x110/0x1c0
        __vma_adjust+0x2b4/0x9b0
        __split_vma+0x1b8/0x280
        __do_munmap+0x13c/0x550
        sys_mremap+0x220/0x7e0
        system_call+0x5c/0x70
      
      Fixes: 675d9952 ("powerpc/book3s64: Enable split pmd ptlock.")
      Cc: stable@vger.kernel.org # v4.18+
      Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      49c473e1
    • S
      firmware: arm_scmi: provide the mandatory device release callback · d4e7c942
      Sudeep Holla 提交于
      commit 46edb8d1322c1763dd04e179992f8e9996085047 upstream.
      
      The device/driver model clearly mandates that bus driver that discover
      and allocate the device must set the release callback. This callback
      will be used to free the device after all references have gone away.
      
      scmi bus driver is missing the obvious callback which will result in
      the following warning if the device is unregistered:
      
      Device 'scmi_dev.1' does not have a release() function, it is broken and
      must be fixed. See Documentation/kobject.txt.
      WARNING at drivers/base/core.c:922 device_release+0x8c/0xa0
      Hardware name: ARM LTD Juno Development Platform BIOS EDK II Jan 21 2019
      Workqueue: events deferred_probe_work_func
      pstate: 60000005 (nZCv daif -PAN -UAO)
      pc : device_release+0x8c/0xa0
      lr : device_release+0x8c/0xa0
      Call trace:
       device_release+0x8c/0xa0
       kobject_put+0x8c/0x208
       device_unregister+0x30/0x78
       scmi_device_destroy+0x28/0x50
       scmi_probe+0x354/0x5b0
       platform_drv_probe+0x58/0xa8
       really_probe+0x2c4/0x3e8
       driver_probe_device+0x12c/0x148
       __device_attach_driver+0xac/0x150
       bus_for_each_drv+0x78/0xd8
       __device_attach+0xe0/0x168
       device_initial_probe+0x24/0x30
       bus_probe_device+0xa0/0xa8
       deferred_probe_work_func+0x8c/0xe0
       process_one_work+0x1f0/0x478
       worker_thread+0x22c/0x450
       kthread+0x134/0x138
       ret_from_fork+0x10/0x1c
      ---[ end trace 420bdb7f6af50937 ]---
      
      Fix the issue by providing scmi_device_release callback. We have
      everything required for device release already in scmi_device_destroy,
      so we just need to move freeing of the device to scmi_device_release.
      
      Fixes: 933c5044 ("firmware: arm_scmi: add scmi protocol bus to enumerate protocol devices")
      Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
      Cc: stable@vger.kernel.org # 4.17+
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d4e7c942
    • B
      ARM: dts: da850: fix interrupt numbers for clocksource · fe3dabb6
      Bartosz Golaszewski 提交于
      commit e3966a766865da7ced1dece663697861dd5cf103 upstream.
      
      The timer interrupts specified in commit 3652e274 ("ARM: dts:
      da850: Add clocks") are wrong but since the current timer code
      hard-codes them, the bug was never spotted.
      
      This patch must go into stable since, once we introduce a proper
      clocksource driver, devices with buggy device tree will stop booting.
      
      Fixes: 3652e274 ("ARM: dts: da850: Add clocks")
      Cc: stable@vger.kernel.org
      Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
      Signed-off-by: NSekhar Nori <nsekhar@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fe3dabb6
    • M
      ARM: tango: Improve ARCH_MULTIPLATFORM compatibility · 33bd0949
      Marc Gonzalez 提交于
      commit d0f9f16788e15d9eb40f68b047732d49658c5a3a upstream.
      
      Calling platform-specific code unconditionally blows up when running
      an ARCH_MULTIPLATFORM kernel on a different platform. Don't do it.
      Reported-by: NPaolo Pisati <p.pisati@gmail.com>
      Signed-off-by: NMarc Gonzalez <marc.w.gonzalez@free.fr>
      Acked-by: NPavel Machek <pavel@ucw.cz>
      Cc: stable@vger.kernel.org # v4.8+
      Fixes: a30eceb7 ("ARM: tango: add Suspend-to-RAM support")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      33bd0949
    • R
      ARM: iop32x/n2100: fix PCI IRQ mapping · 569051e1
      Russell King 提交于
      commit db4090920ba2d61a5827a23e441447926a02ffee upstream.
      
      Booting 4.20 on a TheCUS N2100 results in a kernel oops while probing
      PCI, due to n2100_pci_map_irq() having been discarded during boot.
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      Cc: stable@vger.kernel.org # 2.6.18+
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      569051e1
    • P
      MIPS: VDSO: Include $(ccflags-vdso) in o32,n32 .lds builds · f5b4de05
      Paul Burton 提交于
      commit 67fc5dc8a541e8f458d7f08bf88ff55933bf9f9d upstream.
      
      When generating vdso-o32.lds & vdso-n32.lds for use with programs
      running as compat ABIs under 64b kernels, we previously haven't included
      the compiler flags that are supposedly common to all ABIs - ie. those in
      the ccflags-vdso variable.
      
      This is problematic in cases where we need to provide the -m%-float flag
      in order to ensure that we don't attempt to use a floating point ABI
      that's incompatible with the target CPU & ABI. For example a toolchain
      using current gcc trunk configured --with-fp-32=xx fails to build a
      64r6el_defconfig kernel with the following error:
      
        cc1: error: '-march=mips1' requires '-mfp32'
        make[2]: *** [arch/mips/vdso/Makefile:135: arch/mips/vdso/vdso-o32.lds] Error 1
      
      Include $(ccflags-vdso) for the compat VDSO .lds builds, just as it is
      included for the native VDSO .lds & when compiling objects for the
      compat VDSOs. This ensures we consistently provide the -msoft-float flag
      amongst others, avoiding the problem by ensuring we're agnostic to the
      toolchain defaults.
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Fixes: ebb5e78c ("MIPS: Initial implementation of a VDSO")
      Cc: linux-mips@vger.kernel.org
      Cc: Kevin Hilman <khilman@baylibre.com>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: Maciej W . Rozycki <macro@linux-mips.org>
      Cc: stable@vger.kernel.org # v4.4+
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f5b4de05
    • Y
      mips: loongson64: remove unreachable(), fix loongson_poweroff(). · 814e4450
      Yifeng Li 提交于
      commit 8a96669d77897ff3613157bf43f875739205d66d upstream.
      
      On my Yeeloong 8089, I noticed the machine fails to shutdown
      properly, and often, the function mach_prepare_reboot() is
      unexpectedly executed, thus the machine reboots instead. A
      wait loop is needed to ensure the system is in a well-defined
      state before going down.
      
      In commit 997e93d4 ("MIPS: Hang more efficiently on
      halt/powerdown/restart"), a general superset of the wait loop for all
      platforms is already provided, so we don't need to implement our own.
      
      This commit simply removes the unreachable() compiler marco after
      mach_prepare_reboot(), thus allowing the execution of machine_hang().
      My test shows that the machine is now able to shutdown successfully.
      
      Please note that there are two different bugs preventing the machine
      from shutting down, another work-in-progress commit is needed to
      fix a lockup in cpufreq / i8259 driver, please read Reference, this
      commit does not fix that bug.
      
      Reference: https://lkml.org/lkml/2019/2/5/908Signed-off-by: NYifeng Li <tomli@tomli.me>
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Cc: linux-mips@vger.kernel.org
      Cc: Huacai Chen <chenhc@lemote.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
      Cc: stable@vger.kernel.org # v4.17+
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      814e4450
    • P
      MIPS: VDSO: Use same -m%-float cflag as the kernel proper · e32ba28e
      Paul Burton 提交于
      commit 0648e50e548d881d025b9419a1a168753c8e2bf7 upstream.
      
      The MIPS VDSO build currently doesn't provide the -msoft-float flag to
      the compiler as the kernel proper does. This results in an attempt to
      use the compiler's default floating point configuration, which can be
      problematic in cases where this is incompatible with the target CPU's
      -march= flag. For example decstation_defconfig fails to build using
      toolchains in which gcc was configured --with-fp-32=xx with the
      following error:
      
          LDS     arch/mips/vdso/vdso.lds
        cc1: error: '-march=r3000' requires '-mfp32'
        make[2]: *** [scripts/Makefile.build:379: arch/mips/vdso/vdso.lds] Error 1
      
      The kernel proper avoids this error because we build with the
      -msoft-float compiler flag, rather than using the compiler's default.
      Pass this flag through to the VDSO build so that it too becomes agnostic
      to the toolchain's floating point configuration.
      
      Note that this is filtered out from KBUILD_CFLAGS rather than simply
      always using -msoft-float such that if we switch the kernel to use
      -mno-float in the future the VDSO will automatically inherit the change.
      
      The VDSO doesn't actually include any floating point code, and its
      .MIPS.abiflags section is already manually generated to specify that
      it's compatible with any floating point ABI. As such this change should
      have no effect on the resulting VDSO, apart from fixing the build
      failure for affected toolchains.
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Reported-by: NKevin Hilman <khilman@baylibre.com>
      Reported-by: NGuenter Roeck <linux@roeck-us.net>
      Tested-by: NKevin Hilman <khilman@baylibre.com>
      References: https://lore.kernel.org/linux-mips/1477843551-21813-1-git-send-email-linux@roeck-us.net/
      References: https://kernelci.org/build/id/5c4e4ae059b5142a249ad004/logs/
      Fixes: ebb5e78c ("MIPS: Initial implementation of a VDSO")
      Cc: Maciej W. Rozycki <macro@linux-mips.org>
      Cc: linux-mips@vger.kernel.org
      Cc: stable@vger.kernel.org # v4.4+
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e32ba28e
    • A
      MIPS: OCTEON: don't set octeon_dma_bar_type if PCI is disabled · 264b2620
      Aaro Koskinen 提交于
      commit dcf300a69ac307053dfb35c2e33972e754a98bce upstream.
      
      Don't set octeon_dma_bar_type if PCI is disabled. This avoids creation
      of the MSI irqchip later on, and saves a bit of memory.
      Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Fixes: a214720cbf50 ("Disable MSI also when pcie-octeon.pcie_disable on")
      Cc: stable@vger.kernel.org # v3.3+
      Cc: linux-mips@vger.kernel.org
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      264b2620
    • V
      mips: cm: reprime error cause · 384cc5fd
      Vladimir Kondratiev 提交于
      commit 05dc6001af0630e200ad5ea08707187fe5537e6d upstream.
      
      Accordingly to the documentation
      ---cut---
      The GCR_ERROR_CAUSE.ERR_TYPE field and the GCR_ERROR_MULT.ERR_TYPE
      fields can be cleared by either a reset or by writing the current
      value of GCR_ERROR_CAUSE.ERR_TYPE to the
      GCR_ERROR_CAUSE.ERR_TYPE register.
      ---cut---
      Do exactly this. Original value of cm_error may be safely written back;
      it clears error cause and keeps other bits untouched.
      
      Fixes: 3885c2b4 ("MIPS: CM: Add support for reporting CM cache errors")
      Signed-off-by: NVladimir Kondratiev <vladimir.kondratiev@linux.intel.com>
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: linux-mips@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: stable@vger.kernel.org # v4.3+
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      384cc5fd
    • A
      tracing: uprobes: Fix typo in pr_fmt string · 7e44aab9
      Andreas Ziegler 提交于
      commit ea6eb5e7d15e1838de335609994b4546e2abcaaf upstream.
      
      The subsystem-specific message prefix for uprobes was also
      "trace_kprobe: " instead of "trace_uprobe: " as described in
      the original commit message.
      
      Link: http://lkml.kernel.org/r/20190117133023.19292-1-andreas.ziegler@fau.de
      
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: stable@vger.kernel.org
      Acked-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Fixes: 72576341 ("tracing/probe: Show subsystem name in messages")
      Signed-off-by: NAndreas Ziegler <andreas.ziegler@fau.de>
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7e44aab9
    • D
      pinctrl: cherryview: fix Strago DMI workaround · 9b66753c
      Dmitry Torokhov 提交于
      commit e3f72b749da2bf63bed7409e416f160418d475b6 upstream.
      
      Well, hopefully 3rd time is a charm. We tried making that check
      DMI_BIOS_VERSION and DMI_BOARD_VERSION, but the real one is
      DMI_PRODUCT_VERSION.
      
      Fixes: 86c5dd68 ("pinctrl: cherryview: limit Strago DMI workarounds to version 1.0")
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=197953
      Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1631930
      Cc: stable@vger.kernel.org
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9b66753c
    • C
      pinctrl: sunxi: Correct number of IRQ banks on H6 main pin controller · 93f6fb60
      Chen-Yu Tsai 提交于
      commit 10098709b4ee6f6f19f25ba81d9c6f83518c584c upstream.
      
      The H6 main pin controller has four banks of interrupt-triggering pins.
      The driver as originally submitted only specified three, but had pin
      descriptions referencing a fourth bank. This results in a out-of-bounds
      access into .irq_array of struct sunxi_pinctrl. This however did not
      result in a crash until v4.20, with commit a66d972465d1 ("devres: Align
      data[] to ARCH_KMALLOC_MINALIGN"), which changed the alignment of memory
      region returned by devm_kcalloc(). The increase likely moved the
      out-of-bounds access into the next, unmapped page.
      
      With KASAN on, the bug is quite clear:
      
          BUG: KASAN: slab-out-of-bounds in sunxi_pinctrl_init_with_variant+0x49c/0x12b8
          Write of size 4 at addr ffff80002c680280 by task swapper/0/1
      
          CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.0.0-rc1-00016-gc480a5e6a077 #3
          Hardware name: OrangePi Lite2 (DT)
          Call trace:
           dump_backtrace+0x0/0x220
           show_stack+0x14/0x20
           dump_stack+0xac/0xd4
           print_address_description+0x60/0x25c
           kasan_report+0x14c/0x1ac
           __asan_store4+0x80/0xa0
           sunxi_pinctrl_init_with_variant+0x49c/0x12b8
           h6_pinctrl_probe+0x18/0x20
           platform_drv_probe+0x6c/0xc8
           really_probe+0x244/0x4b0
           driver_probe_device.part.4+0x11c/0x164
           __driver_attach+0x120/0x190
           bus_for_each_dev+0xe8/0x158
           driver_attach+0x30/0x40
           bus_add_driver+0x308/0x318
           driver_register+0xbc/0x1d0
           __platform_driver_register+0x7c/0x88
           h6_pinctrl_driver_init+0x18/0x20
           do_one_initcall+0xd4/0x208
           kernel_init_freeable+0x230/0x2c8
           kernel_init+0x10/0x108
           ret_from_fork+0x10/0x1c
      
          Allocated by task 1:
           kasan_kmalloc.part.0+0x4c/0x100
           kasan_kmalloc+0xc4/0xe8
           kasan_slab_alloc+0x14/0x20
           __kmalloc_track_caller+0x130/0x238
           devm_kmalloc+0x34/0xd0
           sunxi_pinctrl_init_with_variant+0x1d8/0x12b8
           h6_pinctrl_probe+0x18/0x20
           platform_drv_probe+0x6c/0xc8
           really_probe+0x244/0x4b0
           driver_probe_device.part.4+0x11c/0x164
           __driver_attach+0x120/0x190
           bus_for_each_dev+0xe8/0x158
           driver_attach+0x30/0x40
           bus_add_driver+0x308/0x318
           driver_register+0xbc/0x1d0
           __platform_driver_register+0x7c/0x88
           h6_pinctrl_driver_init+0x18/0x20
           do_one_initcall+0xd4/0x208
           kernel_init_freeable+0x230/0x2c8
           kernel_init+0x10/0x108
           ret_from_fork+0x10/0x1c
      
          Freed by task 0:
          (stack is not available)
      
          The buggy address belongs to the object at ffff80002c680080
           which belongs to the cache kmalloc-512 of size 512
          The buggy address is located 0 bytes to the right of
           512-byte region [ffff80002c680080, ffff80002c680280)
          The buggy address belongs to the page:
          page:ffff7e0000b1a000 count:1 mapcount:0 mapping:ffff80002e00c780 index:0xffff80002c683c80 compound_mapcount: 0
          flags: 0x10200(slab|head)
          raw: 0000000000010200 ffff80002e003a10 ffff80002e003a10 ffff80002e00c780
          raw: ffff80002c683c80 0000000000100001 00000001ffffffff 0000000000000000
          page dumped because: kasan: bad access detected
      
          Memory state around the buggy address:
           ffff80002c680180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
           ffff80002c680200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
          >ffff80002c680280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      		       ^
           ffff80002c680300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
           ffff80002c680380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      
      Correct the number of IRQ banks so there are no more mismatches.
      
      Fixes: c8a83090 ("pinctrl: sunxi: add support for the Allwinner H6 main pin controller")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NChen-Yu Tsai <wens@csie.org>
      Tested-by: NNeil Armstrong <narmstrong@baylibre.com>
      Acked-by: NMaxime Ripard <maxime.ripard@bootlin.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      93f6fb60
    • G
      debugfs: fix debugfs_rename parameter checking · c619140d
      Greg Kroah-Hartman 提交于
      commit d88c93f090f708c18195553b352b9f205e65418f upstream.
      
      debugfs_rename() needs to check that the dentries passed into it really
      are valid, as sometimes they are not (i.e. if the return value of
      another debugfs call is passed into this one.)  So fix this up by
      properly checking if the two parent directories are errors (they are
      allowed to be NULL), and if the dentry to rename is not NULL or an
      error.
      
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c619140d
    • T
      samples: mei: use /dev/mei0 instead of /dev/mei · 0c548bab
      Tomas Winkler 提交于
      commit c4a46acf1db3ce547d290c29e55b3476c78dd76c upstream.
      
      The device was moved from misc device to character devices
      to support multiple mei devices.
      
      Cc: <stable@vger.kernel.org> #v4.9+
      Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0c548bab
    • T
      mei: me: add ice lake point device id. · edd8fb55
      Tomas Winkler 提交于
      commit efe814e90b98aed6d655b5a4092b9114b8b26e42 upstream.
      
      Add icelake mei device id.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      edd8fb55
    • D
      misc: vexpress: Off by one in vexpress_syscfg_exec() · db5f65bf
      Dan Carpenter 提交于
      commit f8a70d8b889f180e6860cb1f85fed43d37844c5a upstream.
      
      The > comparison should be >= to prevent reading beyond the end of the
      func->template[] array.
      
      (The func->template array is allocated in vexpress_syscfg_regmap_init()
      and it has func->num_templates elements.)
      
      Fixes: 974cc7b9 ("mfd: vexpress: Define the device as MFD cells")
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Acked-by: NSudeep Holla <sudeep.holla@arm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      db5f65bf
    • E
      signal: Better detection of synchronous signals · 959e46af
      Eric W. Biederman 提交于
      commit 7146db3317c67b517258cb5e1b08af387da0618b upstream.
      
      Recently syzkaller was able to create unkillablle processes by
      creating a timer that is delivered as a thread local signal on SIGHUP,
      and receiving SIGHUP SA_NODEFERER.  Ultimately causing a loop failing
      to deliver SIGHUP but always trying.
      
      When the stack overflows delivery of SIGHUP fails and force_sigsegv is
      called.  Unfortunately because SIGSEGV is numerically higher than
      SIGHUP next_signal tries again to deliver a SIGHUP.
      
      From a quality of implementation standpoint attempting to deliver the
      timer SIGHUP signal is wrong.  We should attempt to deliver the
      synchronous SIGSEGV signal we just forced.
      
      We can make that happening in a fairly straight forward manner by
      instead of just looking at the signal number we also look at the
      si_code.  In particular for exceptions (aka synchronous signals) the
      si_code is always greater than 0.
      
      That still has the potential to pick up a number of asynchronous
      signals as in a few cases the same si_codes that are used
      for synchronous signals are also used for asynchronous signals,
      and SI_KERNEL is also included in the list of possible si_codes.
      
      Still the heuristic is much better and timer signals are definitely
      excluded.  Which is enough to prevent all known ways for someone
      sending a process signals fast enough to cause unexpected and
      arguably incorrect behavior.
      
      Cc: stable@vger.kernel.org
      Fixes: a27341cd ("Prioritize synchronous signals over 'normal' signals")
      Tested-by: NDmitry Vyukov <dvyukov@google.com>
      Reported-by: NDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      959e46af
    • E
      signal: Always notice exiting tasks · f681f268
      Eric W. Biederman 提交于
      commit 35634ffa1751b6efd8cf75010b509dcb0263e29b upstream.
      
      Recently syzkaller was able to create unkillablle processes by
      creating a timer that is delivered as a thread local signal on SIGHUP,
      and receiving SIGHUP SA_NODEFERER.  Ultimately causing a loop
      failing to deliver SIGHUP but always trying.
      
      Upon examination it turns out part of the problem is actually most of
      the solution.  Since 2.5 signal delivery has found all fatal signals,
      marked the signal group for death, and queued SIGKILL in every threads
      thread queue relying on signal->group_exit_code to preserve the
      information of which was the actual fatal signal.
      
      The conversion of all fatal signals to SIGKILL results in the
      synchronous signal heuristic in next_signal kicking in and preferring
      SIGHUP to SIGKILL.  Which is especially problematic as all
      fatal signals have already been transformed into SIGKILL.
      
      Instead of dequeueing signals and depending upon SIGKILL to
      be the first signal dequeued, first test if the signal group
      has already been marked for death.  This guarantees that
      nothing in the signal queue can prevent a process that needs
      to exit from exiting.
      
      Cc: stable@vger.kernel.org
      Tested-by: NDmitry Vyukov <dvyukov@google.com>
      Reported-by: NDmitry Vyukov <dvyukov@google.com>
      Ref: ebf5ebe31d2c ("[PATCH] signal-fixes-2.5.59-A4")
      History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.gitSigned-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f681f268
    • D
      iio: ti-ads8688: Update buffer allocation for timestamps · 3e17af25
      Dan Murphy 提交于
      commit f214ff521fb1f861c8d7f7d0af98b06bf61b3369 upstream.
      
      Per Jonathan Cameron, the buffer needs to allocate room for a
      64 bit timestamp as well as the channels.  Change the buffer
      to allocate this additional space.
      
      Fixes: 2a864877 ("iio: adc: ti-ads8688: add trigger and buffer support")
      Signed-off-by: NDan Murphy <dmurphy@ti.com>
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3e17af25
    • M
      iio: chemical: atlas-ph-sensor: correct IIO_TEMP values to millicelsius · af770a15
      Matt Ranostay 提交于
      commit 0808831dc62e90023ad14ff8da4804c7846e904b upstream.
      
      IIO_TEMP scale value for temperature was incorrect and not in millicelsius
      as required by the ABI documentation.
      Signed-off-by: NMatt Ranostay <matt.ranostay@konsulko.com>
      Fixes: 27dec00e (iio: chemical: add Atlas pH-SM sensor support)
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      af770a15
    • H
      iio: adc: axp288: Fix TS-pin handling · 38d28640
      Hans de Goede 提交于
      commit 9bcf15f75cac3c6a00d8f8083a635de9c8537799 upstream.
      
      Prior to this commit there were 3 issues with our handling of the TS-pin:
      
      1) There are 2 ways how the firmware can disable monitoring of the TS-pin
      for designs which do not have a temperature-sensor for the battery:
      a) Clearing bit 0 of the AXP20X_ADC_EN1 register
      b) Setting bit 2 of the AXP288_ADC_TS_PIN_CTRL monitoring
      
      Prior to this commit we were unconditionally setting both bits to the
      value used on devices with a TS. This causes the temperature protection to
      kick in on devices without a TS, such as the Jumper ezbook v2, causing
      them to not charge under Linux.
      
      This commit fixes this by using regmap_update_bits when updating these 2
      registers, leaving the 2 mentioned bits alone.
      
      The next 2 problems are related to our handling of the current-source
      for the TS-pin. The current-source used for the battery temp-sensor (TS)
      is shared with the GPADC. For proper fuel-gauge and charger operation the
      TS current-source needs to be permanently on. But to read the GPADC we
      need to temporary switch the TS current-source to ondemand, so that the
      GPADC can use it, otherwise we will always read an all 0 value.
      
      2) Problem 2 is we were writing hardcoded values to the ADC TS pin-ctrl
      register, overwriting various other unrelated bits. Specifically we were
      overwriting the current-source setting for the TS and GPIO0 pins, forcing
      it to 80ųA independent of its original setting. On a Chuwi Vi10 tablet
      this was causing us to get a too high adc value (due to a too high
      current-source) resulting in the following errors being logged:
      
      ACPI Error: AE_ERROR, Returned by Handler for [UserDefinedRegion]
      ACPI Error: Method parse/execution failed \_SB.SXP1._TMP, AE_ERROR
      
      This commit fixes this by using regmap_update_bits to change only the
      relevant bits.
      
      3) After reading the GPADC channel we were unconditionally enabling the
      TS current-source even on devices where the TS-pin is not used and the
      current-source thus was off before axp288_adc_read_raw call.
      
      This commit fixes this by making axp288_adc_set_ts a nop on devices where
      the ADC is not enabled for the TS-pin.
      
      BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1610545
      Fixes: 3091141d ("iio: adc: axp288: Fix the GPADC pin ...")
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      38d28640