1. 12 Jul, 2019 2 commits
  2. 11 Jul, 2019 1 commit
  3. 10 Jul, 2019 37 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.14.133 · aea8526e
      Greg Kroah-Hartman authored
    • Stanislaw Gruszka's avatar
      stable/btrfs: fix backport bug in d819d97e ("btrfs: honor path->skip_locking in backref code") · c875ac0a
      Stanislaw Gruszka authored
      Upstream commit 38e3eebff643 ("btrfs: honor path->skip_locking in
      backref code") was incorrectly backported to 4.14.y . It misses removal
      of two lines from original commit, what cause deadlock.
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203993Reported-by: default avatarOlivier Mazouffre <olivier.mazouffre@ims-bordeaux.fr>
      Fixes: d819d97e ("btrfs: honor path->skip_locking in backref code")
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Reviewed-by: default avatarNikolay Borisov <nborisov@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Yibin Gong's avatar
      dmaengine: imx-sdma: remove BD_INTR for channel0 · 93ca6e20
      Yibin Gong authored
      commit 3f93a4f297961c12bb17aa16cb3a4d1291823cae upstream.
      It is possible for an irq triggered by channel0 to be received later
      after clks are disabled once firmware loaded during sdma probe. If
      that happens then clearing them by writing to SDMA_H_INTR won't work
      and the kernel will hang processing infinite interrupts. Actually,
      don't need interrupt triggered on channel0 since it's pollling
      SDMA_H_STATSTOP to know channel0 done rather than interrupt in
      current code, just clear BD_INTR to disable channel0 interrupt to
      avoid the above case.
      This issue was brought by commit 1d069bfa ("dmaengine: imx-sdma:
      ack channel 0 IRQ in the interrupt handler") which didn't take care
      the above case.
      Fixes: 1d069bfa ("dmaengine: imx-sdma: ack channel 0 IRQ in the interrupt handler")
      Cc: stable@vger.kernel.org #5.0+
      Signed-off-by: Yibin Gong's avatarRobin Gong <yibin.gong@nxp.com>
      Reported-by: default avatarSven Van Asbroeck <thesven73@gmail.com>
      Tested-by: default avatarSven Van Asbroeck <thesven73@gmail.com>
      Reviewed-by: default avatarMichael Olbrich <m.olbrich@pengutronix.de>
      Signed-off-by: default avatarVinod Koul <vkoul@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Dmitry Korotin's avatar
      MIPS: Add missing EHB in mtc0 -> mfc0 sequence. · 377bea40
      Dmitry Korotin authored
      commit 0b24cae4d535045f4c9e177aa228d4e97bad212c upstream.
      Add a missing EHB (Execution Hazard Barrier) in mtc0 -> mfc0 sequence.
      Without this execution hazard barrier it's possible for the value read
      back from the KScratch register to be the value from before the mtc0.
      Reproducible on P5600 & P6600.
      The hazard is documented in the MIPS Architecture Reference Manual Vol.
      III: MIPS32/microMIPS32 Privileged Resource Architecture (MD00088), rev
      6.03 table 8.1 which includes:
         Producer | Consumer | Hazard
         mtc0     | mfc0     | any coprocessor 0 register
      Signed-off-by: default avatarDmitry Korotin <dkorotin@wavecomp.com>
        - Commit message tweaks.
        - Add Fixes tags.
        - Mark for stable back to v3.15 where P5600 support was introduced.]
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Fixes: 3d8bfdd0 ("MIPS: Use C0_KScratch (if present) to hold PGD pointer.")
      Fixes: 829dcc0a ("MIPS: Add MIPS P5600 probe support")
      Cc: linux-mips@vger.kernel.org
      Cc: stable@vger.kernel.org # v3.15+
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Hauke Mehrtens's avatar
      MIPS: Fix bounds check virt_addr_valid · 7e9c43e0
      Hauke Mehrtens authored
      commit d6ed083f5cc621e15c15b56c3b585fd524dbcb0f upstream.
      The bounds check used the uninitialized variable vaddr, it should use
      the given parameter kaddr instead. When using the uninitialized value
      the compiler assumed it to be 0 and optimized this function to just
      return 0 in all cases.
      This should make the function check the range of the given address and
      only do the page map check in case it is in the expected range of
      virtual addresses.
      Fixes: 074a1e1167af ("MIPS: Bounds check virt_addr_valid")
      Cc: stable@vger.kernel.org # v4.12+
      Cc: Paul Burton <paul.burton@mips.com>
      Signed-off-by: default avatarHauke Mehrtens <hauke@hauke-m.de>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Cc: ralf@linux-mips.org
      Cc: jhogan@kernel.org
      Cc: f4bug@amsat.org
      Cc: linux-mips@vger.kernel.org
      Cc: ysu@wavecomp.com
      Cc: jcristau@debian.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Chuck Lever's avatar
      svcrdma: Ignore source port when computing DRC hash · 44b14046
      Chuck Lever authored
      commit 1e091c3bbf51d34d5d96337a59ce5ab2ac3ba2cc upstream.
      The DRC appears to be effectively empty after an RPC/RDMA transport
      reconnect. The problem is that each connection uses a different
      source port, which defeats the DRC hash.
      Clients always have to disconnect before they send retransmissions
      to reset the connection's credit accounting, thus every retransmit
      on NFS/RDMA will miss the DRC.
      An NFS/RDMA client's IP source port is meaningless for RDMA
      transports. The transport layer typically sets the source port value
      on the connection to a random ephemeral port. The server already
      ignores it for the "secure port" check. See commit 16e4d93f
      ("NFSD: Ignore client's source port on RDMA transports").
      The Linux NFS server's DRC resolves XID collisions from the same
      source IP address by using the checksum of the first 200 bytes of
      the RPC call header.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Cc: stable@vger.kernel.org # v4.14+
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Wanpeng Li's avatar
      KVM: LAPIC: Fix pending interrupt in IRR blocked by software disable LAPIC · 3fd88195
      Wanpeng Li authored
      commit bb34e690e9340bc155ebed5a3d75fc63ff69e082 upstream.
      Thomas reported that:
       | Background:
       |    In preparation of supporting IPI shorthands I changed the CPU offline
       |    code to software disable the local APIC instead of just masking it.
       |    That's done by clearing the APIC_SPIV_APIC_ENABLED bit in the APIC_SPIV
       |    register.
       | Failure:
       |    When the CPU comes back online the startup code triggers occasionally
       |    the warning in apic_pending_intr_clear(). That complains that the IRRs
       |    are not empty.
       |    The offending vector is the local APIC timer vector who's IRR bit is set
       |    and stays set.
       | It took me quite some time to reproduce the issue locally, but now I can
       | see what happens.
       | It requires apicv_enabled=0, i.e. full apic emulation. With apicv_enabled=1
       | (and hardware support) it behaves correctly.
       | Here is the series of events:
       |     Guest CPU
       |     goes down
       |       native_cpu_disable()
       | 			apic_soft_disable();
       |     play_dead()
       |     ....
       |     startup()
       |       if (apic_enabled())
       |         apic_pending_intr_clear()	<- Not taken
       |      enable APIC
       |         apic_pending_intr_clear()	<- Triggers warning because IRR is stale
       | When this happens then the deadline timer or the regular APIC timer -
       | happens with both, has fired shortly before the APIC is disabled, but the
       | interrupt was not serviced because the guest CPU was in an interrupt
       | disabled region at that point.
       | The state of the timer vector ISR/IRR bits:
       |     	     	       	        ISR     IRR
       | before apic_soft_disable()    0	      1
       | after apic_soft_disable()     0	      1
       | On startup		      		 0	      1
       | Now one would assume that the IRR is cleared after the INIT reset, but this
       | happens only on CPU0.
       | Why?
       | Because our CPU0 hotplug is just for testing to make sure nothing breaks
       | and goes through an NMI wakeup vehicle because INIT would send it through
       | the boots-trap code which is not really working if that CPU was not
       | physically unplugged.
       | Now looking at a real world APIC the situation in that case is:
       |     	     	       	      	ISR     IRR
       | before apic_soft_disable()    0	      1
       | after apic_soft_disable()     0	      1
       | On startup		      		 0	      0
       | Why?
       | Once the dying CPU reenables interrupts the pending interrupt gets
       | delivered as a spurious interupt and then the state is clear.
       | While that CPU0 hotplug test case is surely an esoteric issue, the APIC
       | emulation is still wrong, Even if the play_dead() code would not enable
       | interrupts then the pending IRR bit would turn into an ISR .. interrupt
       | when the APIC is reenabled on startup.
      From SDM Local APIC State After It Has Been Software Disabled
      * Pending interrupts in the IRR and ISR registers are held and require
        masking or handling by the CPU.
      In Thomas's testing, hardware cpu will not respect soft disable LAPIC
      when IRR has already been set or APICv posted-interrupt is in flight,
      so we can skip soft disable APIC checking when clearing IRR and set ISR,
      continue to respect soft disable APIC when attempting to set IRR.
      Reported-by: default avatarRong Chen <rong.a.chen@intel.com>
      Reported-by: default avatarFeng Tang <feng.tang@intel.com>
      Reported-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Tested-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Rong Chen <rong.a.chen@intel.com>
      Cc: Feng Tang <feng.tang@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarWanpeng Li <wanpengli@tencent.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Paolo Bonzini's avatar
      KVM: x86: degrade WARN to pr_warn_ratelimited · 8b90c980
      Paolo Bonzini authored
      commit 3f16a5c318392cbb5a0c7a3d19dff8c8ef3c38ee upstream.
      This warning can be triggered easily by userspace, so it should certainly not
      cause a panic if panic_on_warn is set.
      Reported-by: syzbot+c03f30b4f4c46bdf8575@syzkaller.appspotmail.com
      Suggested-by: default avatarAlexander Potapenko <glider@google.com>
      Acked-by: default avatarAlexander Potapenko <glider@google.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Vineet Gupta's avatar
      ARC: handle gcc generated __builtin_trap for older compiler · 3b851f87
      Vineet Gupta authored
      commit af1be2e2 upstream.
      ARC gcc prior to GNU 2018.03 release didn't have a target specific
      __builtin_trap() implementation, generating default abort() call.
      Implement the abort() call - emulating what newer gcc does for the same,
      as suggested by Arnd.
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Linus Torvalds's avatar
      tty: rocket: fix incorrect forward declaration of 'rp_init()' · 1a18b808
      Linus Torvalds authored
      [ Upstream commit 423ea3255424b954947d167681b71ded1b8fca53 ]
      Make the forward declaration actually match the real function
      definition, something that previous versions of gcc had just ignored.
      This is another patch to fix new warnings from gcc-9 before I start the
      merge window pulls.  I don't want to miss legitimate new warnings just
      because my system update brought a new compiler with new warnings.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
    • Jason Wang's avatar
      vhost: scsi: add weight support · 011942d1
      Jason Wang authored
      commit c1ea02f15ab5efb3e93fc3144d895410bf79fcf2 upstream.
      This patch will check the weight and exit the loop if we exceeds the
      weight. This is useful for preventing scsi kthread from hogging cpu
      which is guest triggerable.
      This addresses CVE-2019-3900.
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Stefan Hajnoczi <stefanha@redhat.com>
      Fixes: 057cbf49 ("tcm_vhost: Initial merge for vhost level target fabric driver")
      Signed-off-by: default avatarJason Wang <jasowang@redhat.com>
      Reviewed-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Reviewed-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: default avatarBalbir Singh <sblbir@amzn.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Jason Wang's avatar
      vhost: vsock: add weight support · 46c7fce7
      Jason Wang authored
      commit e79b431fb901ba1106670bcc80b9b617b25def7d upstream.
      This patch will check the weight and exit the loop if we exceeds the
      weight. This is useful for preventing vsock kthread from hogging cpu
      which is guest triggerable. The weight can help to avoid starving the
      request from on direction while another direction is being processed.
      The value of weight is picked from vhost-net.
      This addresses CVE-2019-3900.
      Cc: Stefan Hajnoczi <stefanha@redhat.com>
      Fixes: 433fc58e ("VSOCK: Introduce vhost_vsock.ko")
      Signed-off-by: default avatarJason Wang <jasowang@redhat.com>
      Reviewed-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarBalbir Singh <sblbir@amzn.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Jason Wang's avatar
      vhost_net: fix possible infinite loop · ae446749
      Jason Wang authored
      commit e2412c07f8f3040593dfb88207865a3cd58680c0 upstream.
      When the rx buffer is too small for a packet, we will discard the vq
      descriptor and retry it for the next packet:
      while ((sock_len = vhost_net_rx_peek_head_len(net, sock->sk,
      					      &busyloop_intr))) {
      	/* On overrun, truncate and discard */
      	if (unlikely(headcount > UIO_MAXIOV)) {
      		iov_iter_init(&msg.msg_iter, READ, vq->iov, 1, 1);
      		err = sock->ops->recvmsg(sock, &msg,
      					 1, MSG_DONTWAIT | MSG_TRUNC);
      		pr_debug("Discarded rx packet: len %zd\n", sock_len);
      This makes it possible to trigger a infinite while..continue loop
      through the co-opreation of two VMs like:
      1) Malicious VM1 allocate 1 byte rx buffer and try to slow down the
         vhost process as much as possible e.g using indirect descriptors or
      2) Malicious VM2 generate packets to VM1 as fast as possible
      Fixing this by checking against weight at the end of RX and TX
      loop. This also eliminate other similar cases when:
      - userspace is consuming the packets in the meanwhile
      - theoretical TOCTOU attack if guest moving avail index back and forth
        to hit the continue after vhost find guest just add new buffers
      This addresses CVE-2019-3900.
      Fixes: d8316f39 ("vhost: fix total length when packets are too short")
      Fixes: 3a4d5c94 ("vhost_net: a kernel-level virtio server")
      Signed-off-by: default avatarJason Wang <jasowang@redhat.com>
      Reviewed-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarBalbir Singh <sblbir@amzn.com>
    • Jason Wang's avatar
      vhost: introduce vhost_exceeds_weight() · c051fb97
      Jason Wang authored
      commit e82b9b0727ff6d665fff2d326162b460dded554d upstream.
      We used to have vhost_exceeds_weight() for vhost-net to:
      - prevent vhost kthread from hogging the cpu
      - balance the time spent between TX and RX
      This function could be useful for vsock and scsi as well. So move it
      to vhost.c. Device must specify a weight which counts the number of
      requests, or it can also specific a byte_weight which counts the
      number of bytes that has been processed.
      Signed-off-by: default avatarJason Wang <jasowang@redhat.com>
      Reviewed-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarBalbir Singh <sblbir@amzn.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Jason Wang's avatar
      vhost_net: introduce vhost_exceeds_weight() · 2c4e518f
      Jason Wang authored
      commit 272f35cb upstream.
      Signed-off-by: default avatarJason Wang <jasowang@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBalbir Singh <sblbir@amzn.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Paolo Abeni's avatar
      vhost_net: use packet weight for rx handler, too · e9dac4ca
      Paolo Abeni authored
      commit db688c24 upstream.
      Similar to commit a2ac9990 ("vhost-net: set packet weight of
      tx polling to 2 * vq size"), we need a packet-based limit for
      handler_rx, too - elsewhere, under rx flood with small packets,
      tx can be delayed for a very long time, even without busypolling.
      The pkt limit applied to handle_rx must be the same applied by
      handle_tx, or we will get unfair scheduling between rx and tx.
      Tying such limit to the queue length makes it less effective for
      large queue length values and can introduce large process
      scheduler latencies, so a constant valued is used - likewise
      the existing bytes limit.
      The selected limit has been validated with PVP[1] performance
      test with different queue sizes:
      queue size		256	512	1024
      baseline		366	354	362
      weight 128		715	723	670
      weight 256		740	745	733
      weight 512		600	460	583
      weight 1024		423	427	418
      A packet weight of 256 gives peek performances in under all the
      tested scenarios.
      No measurable regression in unidirectional performance tests has
      been detected.
      [1] https://developers.redhat.com/blog/2017/06/05/measuring-and-comparing-open-vswitch-performance/Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Acked-by: default avatarJason Wang <jasowang@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBalbir Singh <sblbir@amazon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • haibinzhang(张海斌)'s avatar
      vhost-net: set packet weight of tx polling to 2 * vq size · 6416172c
      haibinzhang(张海斌) authored
      commit a2ac9990 upstream.
      handle_tx will delay rx for tens or even hundreds of milliseconds when tx busy
      polling udp packets with small length(e.g. 1byte udp payload), because setting
      VHOST_NET_WEIGHT takes into account only sent-bytes but no single packet length.
      Ping-Latencies shown below were tested between two Virtual Machines using
      netperf (UDP_STREAM, len=1), and then another machine pinged the client:
      vq size=256
      Packet-Weight   Ping-Latencies(millisecond)
                         min      avg       max
      Origin           3.319   18.489    57.303
      64               1.643    2.021     2.552
      128              1.825    2.600     3.224
      256              1.997    2.710     4.295
      512              1.860    3.171     4.631
      1024             2.002    4.173     9.056
      2048             2.257    5.650     9.688
      4096             2.093    8.508    15.943
      vq size=512
      Packet-Weight   Ping-Latencies(millisecond)
                         min      avg       max
      Origin           6.537   29.177    66.245
      64               2.798    3.614     4.403
      128              2.861    3.820     4.775
      256              3.008    4.018     4.807
      512              3.254    4.523     5.824
      1024             3.079    5.335     7.747
      2048             3.944    8.201    12.762
      4096             4.158   11.057    19.985
      Seems pretty consistent, a small dip at 2 VQ sizes.
      Ring size is a hint from device about a burst size it can tolerate. Based on
      benchmarks, set the weight to 2 * vq size.
      To evaluate this change, another tests were done using netperf(RR, TX) between
      two machines with Intel(R) Xeon(R) Gold 6133 CPU @ 2.50GHz, and vq size was
      tweaked through qemu. Results shown below does not show obvious changes.
      vq size=256 TCP_RR                vq size=512 TCP_RR
      size/sessions/+thu%/+normalize%   size/sessions/+thu%/+normalize%
         1/       1/  -7%/        -2%      1/       1/   0%/        -2%
         1/       4/  +1%/         0%      1/       4/  +1%/         0%
         1/       8/  +1%/        -2%      1/       8/   0%/        +1%
        64/       1/  -6%/         0%     64/       1/  +7%/        +3%
        64/       4/   0%/        +2%     64/       4/  -1%/        +1%
        64/       8/   0%/         0%     64/       8/  -1%/        -2%
       256/       1/  -3%/        -4%    256/       1/  -4%/        -2%
       256/       4/  +3%/        +4%    256/       4/  +1%/        +2%
       256/       8/  +2%/         0%    256/       8/  +1%/        -1%
      vq size=256 UDP_RR                vq size=512 UDP_RR
      size/sessions/+thu%/+normalize%   size/sessions/+thu%/+normalize%
         1/       1/  -5%/        +1%      1/       1/  -3%/        -2%
         1/       4/  +4%/        +1%      1/       4/  -2%/        +2%
         1/       8/  -1%/        -1%      1/       8/  -1%/         0%
        64/       1/  -2%/        -3%     64/       1/  +1%/        +1%
        64/       4/  -5%/        -1%     64/       4/  +2%/         0%
        64/       8/   0%/        -1%     64/       8/  -2%/        +1%
       256/       1/  +7%/        +1%    256/       1/  -7%/         0%
       256/       4/  +1%/        +1%    256/       4/  -3%/        -4%
       256/       8/  +2%/        +2%    256/       8/  +1%/        +1%
      vq size=256 TCP_STREAM            vq size=512 TCP_STREAM
      size/sessions/+thu%/+normalize%   size/sessions/+thu%/+normalize%
        64/       1/   0%/        -3%     64/       1/   0%/         0%
        64/       4/  +3%/        -1%     64/       4/  -2%/        +4%
        64/       8/  +9%/        -4%     64/       8/  -1%/        +2%
       256/       1/  +1%/        -4%    256/       1/  +1%/        +1%
       256/       4/  -1%/        -1%    256/       4/  -3%/         0%
       256/       8/  +7%/        +5%    256/       8/  -3%/         0%
       512/       1/  +1%/         0%    512/       1/  -1%/        -1%
       512/       4/  +1%/        -1%    512/       4/   0%/         0%
       512/       8/  +7%/        -5%    512/       8/  +6%/        -1%
      1024/       1/   0%/        -1%   1024/       1/   0%/        +1%
      1024/       4/  +3%/         0%   1024/       4/  +1%/         0%
      1024/       8/  +8%/        +5%   1024/       8/  -1%/         0%
      2048/       1/  +2%/        +2%   2048/       1/  -1%/         0%
      2048/       4/  +1%/         0%   2048/       4/   0%/        -1%
      2048/       8/  -2%/         0%   2048/       8/   5%/        -1%
      4096/       1/  -2%/         0%   4096/       1/  -2%/         0%
      4096/       4/  +2%/         0%   4096/       4/   0%/         0%
      4096/       8/  +9%/        -2%   4096/       8/  -5%/        -1%
      Acked-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarHaibin Zhang <haibinzhang@tencent.com>
      Signed-off-by: default avatarYunfang Tai <yunfangtai@tencent.com>
      Signed-off-by: default avatarLidong Chen <lidongchen@tencent.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBalbir Singh <sblbir@amazon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Nikolay Borisov's avatar
      btrfs: Ensure replaced device doesn't have pending chunk allocation · c7e678f2
      Nikolay Borisov authored
      commit debd1c065d2037919a7da67baf55cc683fee09f0 upstream.
      Recent FITRIM work, namely bbbf7243d62d ("btrfs: combine device update
      operations during transaction commit") combined the way certain
      operations are recoded in a transaction. As a result an ASSERT was added
      in dev_replace_finish to ensure the new code works correctly.
      Unfortunately I got reports that it's possible to trigger the assert,
      meaning that during a device replace it's possible to have an unfinished
      chunk allocation on the source device.
      This is supposed to be prevented by the fact that a transaction is
      committed before finishing the replace oepration and alter acquiring the
      chunk mutex. This is not sufficient since by the time the transaction is
      committed and the chunk mutex acquired it's possible to allocate a chunk
      depending on the workload being executed on the replaced device. This
      bug has been present ever since device replace was introduced but there
      was never code which checks for it.
      The correct way to fix is to ensure that there is no pending device
      modification operation when the chunk mutex is acquire and if there is
      repeat transaction commit. Unfortunately it's not possible to just
      exclude the source device from btrfs_fs_devices::dev_alloc_list since
      this causes ENOSPC to be hit in transaction commit.
      Fixing that in another way would need to add special cases to handle the
      last writes and forbid new ones. The looped transaction fix is more
      obvious, and can be easily backported. The runtime of dev-replace is
      long so there's no noticeable delay caused by that.
      Reported-by: default avatarDavid Sterba <dsterba@suse.com>
      Fixes: 391cd9df ("Btrfs: fix unprotected alloc list insertion during the finishing procedure of replace")
      CC: stable@vger.kernel.org # 4.4+
      Signed-off-by: default avatarNikolay Borisov <nborisov@suse.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Shakeel Butt's avatar
      mm/vmscan.c: prevent useless kswapd loops · 584810d3
      Shakeel Butt authored
      commit dffcac2cb88e4ec5906235d64a83d802580b119e upstream.
      In production we have noticed hard lockups on large machines running
      large jobs due to kswaps hoarding lru lock within isolate_lru_pages when
      sc->reclaim_idx is 0 which is a small zone.  The lru was couple hundred
      GiBs and the condition (page_zonenum(page) > sc->reclaim_idx) in
      isolate_lru_pages() was basically skipping GiBs of pages while holding
      the LRU spinlock with interrupt disabled.
      On further inspection, it seems like there are two issues:
      (1) If kswapd on the return from balance_pgdat() could not sleep (i.e.
          node is still unbalanced), the classzone_idx is unintentionally set
          to 0 and the whole reclaim cycle of kswapd will try to reclaim only
          the lowest and smallest zone while traversing the whole memory.
      (2) Fundamentally isolate_lru_pages() is really bad when the
          allocation has woken kswapd for a smaller zone on a very large machine
          running very large jobs.  It can hoard the LRU spinlock while skipping
          over 100s of GiBs of pages.
      This patch only fixes (1).  (2) needs a more fundamental solution.  To
      fix (1), in the kswapd context, if pgdat->kswapd_classzone_idx is
      invalid use the classzone_idx of the previous kswapd loop otherwise use
      the one the waker has requested.
      Link: http://lkml.kernel.org/r/20190701201847.251028-1-shakeelb@google.com
      Fixes: e716f2eb ("mm, vmscan: prevent kswapd sleeping prematurely due to mismatched classzone_idx")
      Signed-off-by: default avatarShakeel Butt <shakeelb@google.com>
      Reviewed-by: default avatarYang Shi <yang.shi@linux.alibaba.com>
      Acked-by: default avatarMel Gorman <mgorman@techsingularity.net>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Hillf Danton <hdanton@sina.com>
      Cc: Roman Gushchin <guro@fb.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Petr Mladek's avatar
      ftrace/x86: Remove possible deadlock between register_kprobe() and ftrace_run_update_code() · 0c0b5477
      Petr Mladek authored
      commit d5b844a2cf507fc7642c9ae80a9d585db3065c28 upstream.
      The commit 9f255b632bf12c4dd7 ("module: Fix livepatch/ftrace module text
      permissions race") causes a possible deadlock between register_kprobe()
      and ftrace_run_update_code() when ftrace is using stop_machine().
      The existing dependency chain (in reverse order) is:
      -> #1 (text_mutex){+.+.}:
      -> #0 (cpu_hotplug_lock.rw_sem){++++}:
       Possible unsafe locking scenario:
             CPU0                    CPU1
             ----                    ----
      It is similar problem that has been solved by the commit 2d1e38f5
      ("kprobes: Cure hotplug lock ordering issues"). Many locks are involved.
      To be on the safe side, text_mutex must become a low level lock taken
      after cpu_hotplug_lock.rw_sem.
      This can't be achieved easily with the current ftrace design.
      For example, arm calls set_all_modules_text_rw() already in
      ftrace_arch_code_modify_prepare(), see arch/arm/kernel/ftrace.c.
      This functions is called:
        + outside stop_machine() from ftrace_run_update_code()
        + without stop_machine() from ftrace_module_enable()
      Fortunately, the problematic fix is needed only on x86_64. It is
      the only architecture that calls set_all_modules_text_rw()
      in ftrace path and supports livepatching at the same time.
      Therefore it is enough to move text_mutex handling from the generic
      kernel/trace/ftrace.c into arch/x86/kernel/ftrace.c:
      This patch basically reverts the ftrace part of the problematic
      commit 9f255b632bf12c4dd7 ("module: Fix livepatch/ftrace module
      text permissions race"). And provides x86_64 specific-fix.
      Some refactoring of the ftrace code will be needed when livepatching
      is implemented for arm or nds32. These architectures call
      set_all_modules_text_rw() and use stop_machine() at the same time.
      Link: http://lkml.kernel.org/r/20190627081334.12793-1-pmladek@suse.com
      Fixes: 9f255b632bf12c4dd7 ("module: Fix livepatch/ftrace module text permissions race")
      Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reported-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Reviewed-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Reviewed-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
        As reviewed by Miroslav Benes <mbenes@suse.cz>, removed return value of
        ftrace_run_update_code() as it is a void function.
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Robert Beckett's avatar
      drm/imx: only send event on crtc disable if kept disabled · b50dc7b7
      Robert Beckett authored
      commit 5aeab2bfc9ffa72d3ca73416635cb3785dfc076f upstream.
      The event will be sent as part of the vblank enable during the modeset
      if the crtc is not being kept disabled.
      Fixes: 5f2f9115 ("drm/imx: atomic phase 3 step 1: Use atomic configuration")
      Signed-off-by: default avatarRobert Beckett <bob.beckett@collabora.com>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarPhilipp Zabel <p.zabel@pengutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Robert Beckett's avatar
      drm/imx: notify drm core before sending event during crtc disable · 207b888a
      Robert Beckett authored
      commit 78c68e8f5cd24bd32ba4ca1cdfb0c30cf0642685 upstream.
      Notify drm core before sending pending events during crtc disable.
      This fixes the first event after disable having an old stale timestamp
      by having drm_crtc_vblank_off update the timestamp to now.
      This was seen while debugging weston log message:
      Warning: computed repaint delay is insane: -8212 msec
      This occurred due to:
      1. driver starts up
      2. fbcon comes along and restores fbdev, enabling vblank
      3. vblank_disable_fn fires via timer disabling vblank, keeping vblank
      seq number and time set at current value
      (some time later)
      4. weston starts and does a modeset
      5. atomic commit disables crtc while it does the modeset
      6. ipu_crtc_atomic_disable sends vblank with old seq number and time
      Fixes: a4744786 ("drm/imx: fix crtc vblank state regression")
      Signed-off-by: default avatarRobert Beckett <bob.beckett@collabora.com>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarPhilipp Zabel <p.zabel@pengutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Alex Deucher's avatar
      drm/amdgpu/gfx9: use reset default for PA_SC_FIFO_SIZE · 8f6df3fd
      Alex Deucher authored
      commit 25f09f858835b0e9a06213811031190a17d8ab78 upstream.
      Recommended by the hw team.
      Reviewed-and-Tested-by: default avatarHuang Rui <ray.huang@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Ard Biesheuvel's avatar
      arm64: kaslr: keep modules inside module region when KASAN is enabled · 3fd5ca35
      Ard Biesheuvel authored
      commit 6f496a555d93db7a11d4860b9220d904822f586a upstream.
      When KASLR and KASAN are both enabled, we keep the modules where they
      are, and randomize the placement of the kernel so it is within 2 GB
      of the module region. The reason for this is that putting modules in
      the vmalloc region (like we normally do when KASLR is enabled) is not
      possible in this case, given that the entire vmalloc region is already
      backed by KASAN zero shadow pages, and so allocating dedicated KASAN
      shadow space as required by loaded modules is not possible.
      The default module allocation window is set to [_etext - 128MB, _etext]
      in kaslr.c, which is appropriate for KASLR kernels booted without a
      seed or with 'nokaslr' on the command line. However, as it turns out,
      it is not quite correct for the KASAN case, since it still intersects
      the vmalloc region at the top, where attempts to allocate shadow pages
      will collide with the KASAN zero shadow pages, causing a WARN() and all
      kinds of other trouble. So cap the top end to MODULES_END explicitly
      when running with KASAN.
      Cc: <stable@vger.kernel.org> # 4.9+
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Tested-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Eiichi Tsukata's avatar
      tracing/snapshot: Resize spare buffer if size changed · 90b89546
      Eiichi Tsukata authored
      commit 46cc0b44428d0f0e81f11ea98217fc0edfbeab07 upstream.
      Current snapshot implementation swaps two ring_buffers even though their
      sizes are different from each other, that can cause an inconsistency
      between the contents of buffer_size_kb file and the current buffer size.
      For example:
        # cat buffer_size_kb
        7 (expanded: 1408)
        # echo 1 > events/enable
        # grep bytes per_cpu/cpu0/stats
        bytes: 1441020
        # echo 1 > snapshot             // current:1408, spare:1408
        # echo 123 > buffer_size_kb     // current:123,  spare:1408
        # echo 1 > snapshot             // current:1408, spare:123
        # grep bytes per_cpu/cpu0/stats
        bytes: 1443700
        # cat buffer_size_kb
        123                             // != current:1408
      And also, a similar per-cpu case hits the following WARNING:
        # echo 1 > per_cpu/cpu0/snapshot
        # echo 123 > buffer_size_kb
        # echo 1 > per_cpu/cpu0/snapshot
        WARNING: CPU: 0 PID: 1946 at kernel/trace/trace.c:1607 update_max_tr_single.part.0+0x2b8/0x380
        Modules linked in:
        CPU: 0 PID: 1946 Comm: bash Not tainted 5.2.0-rc6 #20
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-2.fc30 04/01/2014
        RIP: 0010:update_max_tr_single.part.0+0x2b8/0x380
        Code: ff e8 dc da f9 ff 0f 0b e9 88 fe ff ff e8 d0 da f9 ff 44 89 ee bf f5 ff ff ff e8 33 dc f9 ff 41 83 fd f5 74 96 e8 b8 da f9 ff <0f> 0b eb 8d e8 af da f9 ff 0f 0b e9 bf fd ff ff e8 a3 da f9 ff 48
        RSP: 0018:ffff888063e4fca0 EFLAGS: 00010093
        RAX: ffff888066214380 RBX: ffffffff99850fe0 RCX: ffffffff964298a8
        RDX: 0000000000000000 RSI: 00000000fffffff5 RDI: 0000000000000005
        RBP: 1ffff1100c7c9f96 R08: ffff888066214380 R09: ffffed100c7c9f9b
        R10: ffffed100c7c9f9a R11: 0000000000000003 R12: 0000000000000000
        R13: 00000000ffffffea R14: ffff888066214380 R15: ffffffff99851060
        FS:  00007f9f8173c700(0000) GS:ffff88806d000000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 0000000000714dc0 CR3: 0000000066fa6000 CR4: 00000000000006f0
        Call Trace:
         ? trace_array_printk_buf+0x140/0x140
         ? __mutex_lock_slowpath+0x10/0x10
         ? trace_printk_init_buffers+0x60/0x60
         ? selinux_file_permission+0x3b/0x540
         ? tracer_preempt_off+0x38/0x506
         ? trace_printk_init_buffers+0x60/0x60
         ? __ia32_sys_read+0xb0/0xb0
         ? do_syscall_64+0x1f/0x390
      This patch adds resize_buffer_duplicate_size() to check if there is a
      difference between current/spare buffer sizes and resize a spare buffer
      if necessary.
      Link: http://lkml.kernel.org/r/20190625012910.13109-1-devel@etsukata.com
      Cc: stable@vger.kernel.org
      Fixes: ad909e21 ("tracing: Add internal tracing_snapshot() functions")
      Signed-off-by: default avatarEiichi Tsukata <devel@etsukata.com>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Herbert Xu's avatar
      lib/mpi: Fix karactx leak in mpi_powm · 9fbe87fc
      Herbert Xu authored
      commit c8ea9fce2baf7b643384f36f29e4194fa40d33a6 upstream.
      Sometimes mpi_powm will leak karactx because a memory allocation
      failure causes a bail-out that skips the freeing of karactx.  This
      patch moves the freeing of karactx to the end of the function like
      everything else so that it can't be skipped.
      Reported-by: syzbot+f7baccc38dcc1e094e77@syzkaller.appspotmail.com
      Fixes: cdec9cb5 ("crypto: GnuPG based MPI lib - source files...")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Reviewed-by: default avatarEric Biggers <ebiggers@kernel.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Dennis Wassenberg's avatar
      ALSA: hda/realtek - Change front mic location for Lenovo M710q · 76cdeea3
      Dennis Wassenberg authored
      commit bef33e19203dde434bcdf21c449e3fb4f06c2618 upstream.
      On M710q Lenovo ThinkCentre machine, there are two front mics,
      we change the location for one of them to avoid conflicts.
      Signed-off-by: default avatarDennis Wassenberg <dennis.wassenberg@secunet.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Colin Ian King's avatar
      ALSA: usb-audio: fix sign unintended sign extension on left shifts · 4a0a012c
      Colin Ian King authored
      commit 2acf5a3e6e9371e63c9e4ff54d84d08f630467a0 upstream.
      There are a couple of left shifts of unsigned 8 bit values that
      first get promoted to signed ints and hence get sign extended
      on the shift if the top bit of the 8 bit values are set. Fix
      this by casting the 8 bit values to unsigned ints to stop the
      unintentional sign extension.
      Addresses-Coverity: ("Unintended sign extension")
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Takashi Iwai's avatar
      ALSA: line6: Fix write on zero-sized buffer · 37eaa744
      Takashi Iwai authored
      commit 3450121997ce872eb7f1248417225827ea249710 upstream.
      LINE6 drivers allocate the buffers based on the value returned from
      usb_maxpacket() calls.  The manipulated device may return zero for
      this, and this results in the kmalloc() with zero size (and it may
      succeed) while the other part of the driver code writes the packet
      data with the fixed size -- which eventually overwrites.
      This patch adds a simple sanity check for the invalid buffer size for
      avoiding that problem.
      Reported-by: syzbot+219f00fb49874dcaea17@syzkaller.appspotmail.com
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Takashi Sakamoto's avatar
      ALSA: firewire-lib/fireworks: fix miss detection of received MIDI messages · a75995a7
      Takashi Sakamoto authored
      commit 7fbd1753b64eafe21cf842348a40a691d0dee440 upstream.
      In IEC 61883-6, 8 MIDI data streams are multiplexed into single
      MIDI conformant data channel. The index of stream is calculated by
      modulo 8 of the value of data block counter.
      In fireworks, the value of data block counter in CIP header has a quirk
      with firmware version v5.0.0, v5.7.3 and v5.8.0. This brings ALSA
      IEC 61883-1/6 packet streaming engine to miss detection of MIDI
      This commit fixes the miss detection to modify the value of data block
      counter for the modulo calculation.
      For maintainers, this bug exists since a commit 18f5ed36 ("ALSA:
      fireworks/firewire-lib: add support for recent firmware quirk") in Linux
      kernel v4.2. There're many changes since the commit.  This fix can be
      backported to Linux kernel v4.4 or later. I tagged a base commit to the
      backport for your convenience.
      Besides, my work for Linux kernel v5.3 brings heavy code refactoring and
      some structure members are renamed in 'sound/firewire/amdtp-stream.h'.
      The content of this patch brings conflict when merging -rc tree with
      this patch and the latest tree. I request maintainers to solve the
      conflict to replace 'tx_first_dbc' with 'ctx_data.tx.first_dbc'.
      Fixes: df075fee ("ALSA: firewire-lib: complete AM824 data block processing layer")
      Cc: <stable@vger.kernel.org> # v4.4+
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Colin Ian King's avatar
      ALSA: seq: fix incorrect order of dest_client/dest_ports arguments · 90a2692c
      Colin Ian King authored
      commit c3ea60c231446663afd6ea1054da6b7f830855ca upstream.
      There are two occurrances of a call to snd_seq_oss_fill_addr where
      the dest_client and dest_port arguments are in the wrong order. Fix
      this by swapping them around.
      Addresses-Coverity: ("Arguments in wrong order")
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Vincent Whitchurch's avatar
      crypto: cryptd - Fix skcipher instance memory leak · a86c45d2
      Vincent Whitchurch authored
      commit 1a0fad630e0b7cff38e7691b28b0517cfbb0633f upstream.
      cryptd_skcipher_free() fails to free the struct skcipher_instance
      allocated in cryptd_create_skcipher(), leading to a memory leak.  This
      is detected by kmemleak on bootup on ARM64 platforms:
       unreferenced object 0xffff80003377b180 (size 1024):
         comm "cryptomgr_probe", pid 822, jiffies 4294894830 (age 52.760s)
      Fixes: 4e0958d1 ("crypto: cryptd - Add support for skcipher")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarVincent Whitchurch <vincent.whitchurch@axis.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Eric Biggers's avatar
      crypto: user - prevent operating on larval algorithms · d06037bc
      Eric Biggers authored
      commit 21d4120ec6f5b5992b01b96ac484701163917b63 upstream.
      Michal Suchanek reported [1] that running the pcrypt_aead01 test from
      LTP [2] in a loop and holding Ctrl-C causes a NULL dereference of
      alg->cra_users.next in crypto_remove_spawns(), via crypto_del_alg().
      The test repeatedly uses CRYPTO_MSG_NEWALG and CRYPTO_MSG_DELALG.
      The crash occurs when the instance that CRYPTO_MSG_DELALG is trying to
      unregister isn't a real registered algorithm, but rather is a "test
      larval", which is a special "algorithm" added to the algorithms list
      while the real algorithm is still being tested.  Larvals don't have
      initialized cra_users, so that causes the crash.  Normally pcrypt_aead01
      doesn't trigger this because CRYPTO_MSG_NEWALG waits for the algorithm
      to be tested; however, CRYPTO_MSG_NEWALG returns early when interrupted.
      Everything else in the "crypto user configuration" API has this same bug
      too, i.e. it inappropriately allows operating on larval algorithms
      (though it doesn't look like the other cases can cause a crash).
      Fix this by making crypto_alg_match() exclude larval algorithms.
      [1] https://lkml.kernel.org/r/20190625071624.27039-1-msuchanek@suse.de
      [2] https://github.com/linux-test-project/ltp/blob/20190517/testcases/kernel/crypto/pcrypt_aead01.cReported-by: default avatarMichal Suchanek <msuchanek@suse.de>
      Fixes: a38f7907 ("crypto: Add userspace configuration API")
      Cc: <stable@vger.kernel.org> # v3.2+
      Cc: Steffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Jann Horn's avatar
      ptrace: Fix ->ptracer_cred handling for PTRACE_TRACEME · bf71ef96
      Jann Horn authored
      commit 6994eefb0053799d2e07cd140df6c2ea106c41ee upstream.
      Fix two issues:
      When called for PTRACE_TRACEME, ptrace_link() would obtain an RCU
      reference to the parent's objective credentials, then give that pointer
      to get_cred().  However, the object lifetime rules for things like
      struct cred do not permit unconditionally turning an RCU reference into
      a stable reference.
      PTRACE_TRACEME records the parent's credentials as if the parent was
      acting as the subject, but that's not the case.  If a malicious
      unprivileged child uses PTRACE_TRACEME and the parent is privileged, and
      at a later point, the parent process becomes attacker-controlled
      (because it drops privileges and calls execve()), the attacker ends up
      with control over two processes with a privileged ptrace relationship,
      which can be abused to ptrace a suid binary and obtain root privileges.
      Fix both of these by always recording the credentials of the process
      that is requesting the creation of the ptrace relationship:
      current_cred() can't change under us, and current is the proper subject
      for access control.
      This change is theoretically userspace-visible, but I am not aware of
      any code that it will actually break.
      Fixes: 64b875f7 ("ptrace: Capture the ptracer's creds not PT_PTRACE_CAP")
      Signed-off-by: default avatarJann Horn <jannh@google.com>
      Acked-by: default avatarOleg Nesterov <oleg@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Lucas De Marchi's avatar
      drm/i915/dmc: protect against reading random memory · 8a4db13c
      Lucas De Marchi authored
      commit bc7b488b1d1c71dc4c5182206911127bc6c410d6 upstream.
      While loading the DMC firmware we were double checking the headers made
      sense, but in no place we checked that we were actually reading memory
      we were supposed to. This could be wrong in case the firmware file is
      truncated or malformed.
      Before this patch:
      	# ls -l /lib/firmware/i915/icl_dmc_ver1_07.bin
      	-rw-r--r-- 1 root root  25716 Feb  1 12:26 icl_dmc_ver1_07.bin
      	# truncate -s 25700 /lib/firmware/i915/icl_dmc_ver1_07.bin
      	# modprobe i915
      	# dmesg| grep -i dmc
      	[drm:intel_csr_ucode_init [i915]] Loading i915/icl_dmc_ver1_07.bin
      	[drm] Finished loading DMC firmware i915/icl_dmc_ver1_07.bin (v1.7)
      i.e. it loads random data. Now it fails like below:
      	[drm:intel_csr_ucode_init [i915]] Loading i915/icl_dmc_ver1_07.bin
      	[drm:csr_load_work_fn [i915]] *ERROR* Truncated DMC firmware, rejecting.
      	i915 0000:00:02.0: Failed to load DMC firmware i915/icl_dmc_ver1_07.bin. Disabling runtime power management.
      	i915 0000:00:02.0: DMC firmware homepage: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915
      Before reading any part of the firmware file, validate the input first.
      Fixes: eb805623 ("drm/i915/skl: Add support to load SKL CSR firmware.")
      Signed-off-by: default avatarLucas De Marchi <lucas.demarchi@intel.com>
      Reviewed-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190605235535.17791-1-lucas.demarchi@intel.com
      (cherry picked from commit bc7b488b1d1c71dc4c5182206911127bc6c410d6)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      [ Lucas: backported to 4.9+ adjusting the context ]
      Cc: stable@vger.kernel.org # v4.9+
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
    • Paul Burton's avatar
      MIPS: netlogic: xlr: Remove erroneous check in nlm_fmn_send() · dbcbf7dd
      Paul Burton authored
      [ Upstream commit 02eec6c9 ]
      In nlm_fmn_send() we have a loop which attempts to send a message
      multiple times in order to handle the transient failure condition of a
      lack of available credit. When examining the status register to detect
      the failure we check for a condition that can never be true, which falls
      foul of gcc 8's -Wtautological-compare:
        In file included from arch/mips/netlogic/common/irq.c:65:
        ./arch/mips/include/asm/netlogic/xlr/fmn.h: In function 'nlm_fmn_send':
        ./arch/mips/include/asm/netlogic/xlr/fmn.h:304:22: error: bitwise
          comparison always evaluates to false [-Werror=tautological-compare]
           if ((status & 0x2) == 1)
      If the path taken if this condition were true all we do is print a
      message to the kernel console. Since failures seem somewhat expected
      here (making the console message questionable anyway) and the condition
      has clearly never evaluated true we simply remove it, rather than
      attempting to fix it to check status correctly.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/20174/
      Cc: Ganesan Ramalingam <ganesanr@broadcom.com>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Jayachandran C <jnair@caviumnetworks.com>
      Cc: John Crispin <john@phrozen.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
    • Wei Li's avatar
      ftrace: Fix NULL pointer dereference in free_ftrace_func_mapper() · f6880316
      Wei Li authored
      [ Upstream commit 04e03d9a616c19a47178eaca835358610e63a1dd ]
      The mapper may be NULL when called from register_ftrace_function_probe()
      with probe->data == NULL.
      This issue can be reproduced as follow (it may be covered by compiler
      optimization sometime):
      / # cat /sys/kernel/debug/tracing/set_ftrace_filter
      #### all functions enabled ####
      / # echo foo_bar:dump > /sys/kernel/debug/tracing/set_ftrace_filter
      [  206.949100] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
      [  206.952402] Mem abort info:
      [  206.952819]   ESR = 0x96000006
      [  206.955326]   Exception class = DABT (current EL), IL = 32 bits
      [  206.955844]   SET = 0, FnV = 0
      [  206.956272]   EA = 0, S1PTW = 0
      [  206.956652] Data abort info:
      [  206.957320]   ISV = 0, ISS = 0x00000006
      [  206.959271]   CM = 0, WnR = 0
      [  206.959938] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000419f3a000
      [  206.960483] [0000000000000000] pgd=0000000411a87003, pud=0000000411a83003, pmd=0000000000000000
      [  206.964953] Internal error: Oops: 96000006 [#1] SMP
      [  206.971122] Dumping ftrace buffer:
      [  206.973677]    (ftrace buffer empty)
      [  206.975258] Modules linked in:
      [  206.976631] Process sh (pid: 281, stack limit = 0x(____ptrval____))
      [  206.978449] CPU: 10 PID: 281 Comm: sh Not tainted 5.2.0-rc1+ #17
      [  206.978955] Hardware name: linux,dummy-virt (DT)
      [  206.979883] pstate: 60000005 (nZCv daif -PAN -UAO)
      [  206.980499] pc : free_ftrace_func_mapper+0x2c/0x118
      [  206.980874] lr : ftrace_count_free+0x68/0x80
      [  206.982539] sp : ffff0000182f3ab0
      [  206.983102] x29: ffff0000182f3ab0 x28: ffff8003d0ec1700
      [  206.983632] x27: ffff000013054b40 x26: 0000000000000001
      [  206.984000] x25: ffff00001385f000 x24: 0000000000000000
      [  206.984394] x23: ffff000013453000 x22: ffff000013054000
      [  206.984775] x21: 0000000000000000 x20: ffff00001385fe28
      [  206.986575] x19: ffff000013872c30 x18: 0000000000000000
      [  206.987111] x17: 0000000000000000 x16: 0000000000000000
      [  206.987491] x15: ffffffffffffffb0 x14: 0000000000000000
      [  206.987850] x13: 000000000017430e x12: 0000000000000580
      [  206.988251] x11: 0000000000000000 x10: cccccccccccccccc
      [  206.988740] x9 : 0000000000000000 x8 : ffff000013917550
      [  206.990198] x7 : ffff000012fac2e8 x6 : ffff000012fac000
      [  206.991008] x5 : ffff0000103da588 x4 : 0000000000000001
      [  206.991395] x3 : 0000000000000001 x2 : ffff000013872a28
      [  206.991771] x1 : 0000000000000000 x0 : 0000000000000000
      [  206.992557] Call trace:
      [  206.993101]  free_ftrace_func_mapper+0x2c/0x118
      [  206.994827]  ftrace_count_free+0x68/0x80
      [  206.995238]  release_probe+0xfc/0x1d0
      [  206.995555]  register_ftrace_function_probe+0x4a8/0x868
      [  206.995923]  ftrace_trace_probe_callback.isra.4+0xb8/0x180
      [  206.996330]  ftrace_dump_callback+0x50/0x70
      [  206.996663]  ftrace_regex_write.isra.29+0x290/0x3a8
      [  206.997157]  ftrace_filter_write+0x44/0x60
      [  206.998971]  __vfs_write+0x64/0xf0
      [  206.999285]  vfs_write+0x14c/0x2f0
      [  206.999591]  ksys_write+0xbc/0x1b0
      [  206.999888]  __arm64_sys_write+0x3c/0x58
      [  207.000246]  el0_svc_common.constprop.0+0x408/0x5f0
      [  207.000607]  el0_svc_handler+0x144/0x1c8
      [  207.000916]  el0_svc+0x8/0xc
      [  207.003699] Code: aa0003f8 a9025bf5 aa0103f5 f946ea80 (f9400303)
      [  207.008388] ---[ end trace 7b6d11b5f542bdf1 ]---
      [  207.010126] Kernel panic - not syncing: Fatal exception
      [  207.011322] SMP: stopping secondary CPUs
      [  207.013956] Dumping ftrace buffer:
      [  207.014595]    (ftrace buffer empty)
      [  207.015632] Kernel Offset: disabled
      [  207.017187] CPU features: 0x002,20006008
      [  207.017985] Memory Limit: none
      [  207.019825] ---[ end Kernel panic - not syncing: Fatal exception ]---
      Link: http://lkml.kernel.org/r/20190606031754.10798-1-liwei391@huawei.comSigned-off-by: default avatarWei Li <liwei391@huawei.com>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>