1. 26 Jul, 2019 40 commits
    • Paulo Alcantara (SUSE)'s avatar
      cifs: Properly handle auto disabling of serverino option · c0fcf576
      Paulo Alcantara (SUSE) authored
      commit 29fbeb7a upstream.
      
      Fix mount options comparison when serverino option is turned off later
      in cifs_autodisable_serverino() and thus avoiding mismatch of new cifs
      mounts.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarPaulo Alcantara (SUSE) <paulo@paulo.ac>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      Reviewed-by: default avatarPavel Shilovsky <pshilove@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c0fcf576
    • Ronnie Sahlberg's avatar
      cifs: fix crash in smb2_compound_op()/smb2_set_next_command() · 85324afd
      Ronnie Sahlberg authored
      commit 88a92c91 upstream.
      
      RHBZ: 1722704
      
      In low memory situations the various SMB2_*_init() functions can fail
      to allocate a request PDU and thus leave the request iovector as NULL.
      
      If we don't check the return code for failure we end up calling
      smb2_set_next_command() with a NULL iovector causing a crash when it tries
      to dereference it.
      
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: default avatarRonnie Sahlberg <lsahlber@redhat.com>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      85324afd
    • Ronnie Sahlberg's avatar
      cifs: always add credits back for unsolicited PDUs · 43d753fd
      Ronnie Sahlberg authored
      commit 3e272579 upstream.
      
      not just if CONFIG_CIFS_DEBUG2 is enabled.
      Signed-off-by: default avatarRonnie Sahlberg <lsahlber@redhat.com>
      Reviewed-by: default avatarPavel Shilovsky <pshilov@microsoft.com>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      43d753fd
    • Wen Yang's avatar
      crypto: crypto4xx - fix a potential double free in ppc4xx_trng_probe · 54ebe857
      Wen Yang authored
      commit 95566aa7 upstream.
      
      There is a possible double free issue in ppc4xx_trng_probe():
      
      85:	dev->trng_base = of_iomap(trng, 0);
      86:	of_node_put(trng);          ---> released here
      87:	if (!dev->trng_base)
      88:		goto err_out;
      ...
      110:	ierr_out:
      111:		of_node_put(trng);  ---> double released here
      ...
      
      This issue was detected by using the Coccinelle software.
      We fix it by removing the unnecessary of_node_put().
      
      Fixes: 5343e674 ("crypto4xx: integrate ppc4xx-rng into crypto4xx")
      Signed-off-by: default avatarWen Yang <wen.yang99@zte.com.cn>
      Cc: <stable@vger.kernel.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Allison Randal <allison@lohutok.net>
      Cc: Armijn Hemel <armijn@tjaldur.nl>
      Cc: Julia Lawall <Julia.Lawall@lip6.fr>
      Cc: linux-crypto@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Acked-by: default avatarJulia Lawall <julia.lawall@lip6.fr>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      54ebe857
    • Cfir Cohen's avatar
      crypto: ccp/gcm - use const time tag comparison. · bb6b587e
      Cfir Cohen authored
      commit 538a5a07 upstream.
      
      Avoid leaking GCM tag through timing side channel.
      
      Fixes: 36cf515b ("crypto: ccp - Enable support for AES GCM on v5 CCPs")
      Cc: <stable@vger.kernel.org> # v4.12+
      Signed-off-by: default avatarCfir Cohen <cfir@google.com>
      Acked-by: default avatarGary R Hook <ghook@amd.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bb6b587e
    • Hook, Gary's avatar
      crypto: ccp - memset structure fields to zero before reuse · 706393e2
      Hook, Gary authored
      commit 20e833dc upstream.
      
      The AES GCM function reuses an 'op' data structure, which members
      contain values that must be cleared for each (re)use.
      
      This fix resolves a crypto self-test failure:
      alg: aead: gcm-aes-ccp encryption test failed (wrong result) on test vector 2, cfg="two even aligned splits"
      
      Fixes: 36cf515b ("crypto: ccp - Enable support for AES GCM on v5 CCPs")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarGary R Hook <gary.hook@amd.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      706393e2
    • Christian Lamparter's avatar
      crypto: crypto4xx - block ciphers should only accept complete blocks · 0a7ac0e8
      Christian Lamparter authored
      commit 0f7a8137 upstream.
      
      The hardware automatically zero pads incomplete block ciphers
      blocks without raising any errors. This is a screw-up. This
      was noticed by CONFIG_CRYPTO_MANAGER_EXTRA_TESTS tests that
      sent a incomplete blocks and expect them to fail.
      
      This fixes:
      cbc-aes-ppc4xx encryption unexpectedly succeeded on test vector
      "random: len=2409 klen=32"; expected_error=-22, cfg="random:
      may_sleep use_digest src_divs=[96.90%@+2295, 2.34%@+4066,
      0.32%@alignmask+12, 0.34%@+4087, 0.9%@alignmask+1787, 0.1%@+3767]
      iv_offset=6"
      
      ecb-aes-ppc4xx encryption unexpectedly succeeded on test vector
      "random: len=1011 klen=32"; expected_error=-22, cfg="random:
      may_sleep use_digest src_divs=[100.0%@alignmask+20]
      dst_divs=[3.12%@+3001, 96.88%@+4070]"
      
      Cc: Eric Biggers <ebiggers@kernel.org>
      Cc: stable@vger.kernel.org [4.19, 5.0 and 5.1]
      Signed-off-by: default avatarChristian Lamparter <chunkeey@gmail.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0a7ac0e8
    • Christian Lamparter's avatar
      crypto: crypto4xx - fix blocksize for cfb and ofb · 16f0c3e3
      Christian Lamparter authored
      commit 70c4997f upstream.
      
      While the hardware consider them to be blockciphers, the
      reference implementation defines them as streamciphers.
      
      Do the right thing and set the blocksize to 1. This
      was found by CONFIG_CRYPTO_MANAGER_EXTRA_TESTS.
      
      This fixes the following issues:
      skcipher: blocksize for ofb-aes-ppc4xx (16) doesn't match generic impl (1)
      skcipher: blocksize for cfb-aes-ppc4xx (16) doesn't match generic impl (1)
      
      Cc: Eric Biggers <ebiggers@kernel.org>
      Cc: stable@vger.kernel.org
      Fixes: f2a13e7c ("crypto: crypto4xx - enable AES RFC3686, ECB, CFB and OFB offloads")
      Signed-off-by: default avatarChristian Lamparter <chunkeey@gmail.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      16f0c3e3
    • Christian Lamparter's avatar
      crypto: crypto4xx - fix AES CTR blocksize value · 86f6ece4
      Christian Lamparter authored
      commit bfa2ba7d upstream.
      
      This patch fixes a issue with crypto4xx's ctr(aes) that was
      discovered by libcapi's kcapi-enc-test.sh test.
      
      The some of the ctr(aes) encryptions test were failing on the
      non-power-of-two test:
      
      kcapi-enc - Error: encryption failed with error 0
      kcapi-enc - Error: decryption failed with error 0
      [FAILED: 32-bit - 5.1.0-rc1+] 15 bytes: STDIN / STDOUT enc test (128 bits):
      original file (1d100e..cc96184c) and generated file (e3b0c442..1b7852b855)
      [FAILED: 32-bit - 5.1.0-rc1+] 15 bytes: STDIN / STDOUT enc test (128 bits)
      (openssl generated CT): original file (e3b0..5) and generated file (3..8e)
      [PASSED: 32-bit - 5.1.0-rc1+] 15 bytes: STDIN / STDOUT enc test (128 bits)
      (openssl generated PT)
      [FAILED: 32-bit - 5.1.0-rc1+] 15 bytes: STDIN / STDOUT enc test (password):
      original file (1d1..84c) and generated file (e3b..852b855)
      
      But the 16, 32, 512, 65536 tests always worked.
      
      Thankfully, this isn't a hidden hardware problem like previously,
      instead this turned out to be a copy and paste issue.
      
      With this patch, all the tests are passing with and
      kcapi-enc-test.sh gives crypto4xx's a clean bill of health:
       "Number of failures: 0" :).
      
      Cc: stable@vger.kernel.org
      Fixes: 98e87e3d ("crypto: crypto4xx - add aes-ctr support")
      Fixes: f2a13e7c ("crypto: crypto4xx - enable AES RFC3686, ECB, CFB and OFB offloads")
      Signed-off-by: default avatarChristian Lamparter <chunkeey@gmail.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      86f6ece4
    • Eric Biggers's avatar
      crypto: chacha20poly1305 - fix atomic sleep when using async algorithm · 2fd5789c
      Eric Biggers authored
      commit 7545b6c2 upstream.
      
      Clear the CRYPTO_TFM_REQ_MAY_SLEEP flag when the chacha20poly1305
      operation is being continued from an async completion callback, since
      sleeping may not be allowed in that context.
      
      This is basically the same bug that was recently fixed in the xts and
      lrw templates.  But, it's always been broken in chacha20poly1305 too.
      This was found using syzkaller in combination with the updated crypto
      self-tests which actually test the MAY_SLEEP flag now.
      
      Reproducer:
      
          python -c 'import socket; socket.socket(socket.AF_ALG, 5, 0).bind(
          	       ("aead", "rfc7539(cryptd(chacha20-generic),poly1305-generic)"))'
      
      Kernel output:
      
          BUG: sleeping function called from invalid context at include/crypto/algapi.h:426
          in_atomic(): 1, irqs_disabled(): 0, pid: 1001, name: kworker/2:2
          [...]
          CPU: 2 PID: 1001 Comm: kworker/2:2 Not tainted 5.2.0-rc2 #5
          Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-20181126_142135-anatol 04/01/2014
          Workqueue: crypto cryptd_queue_worker
          Call Trace:
           __dump_stack lib/dump_stack.c:77 [inline]
           dump_stack+0x4d/0x6a lib/dump_stack.c:113
           ___might_sleep kernel/sched/core.c:6138 [inline]
           ___might_sleep.cold.19+0x8e/0x9f kernel/sched/core.c:6095
           crypto_yield include/crypto/algapi.h:426 [inline]
           crypto_hash_walk_done+0xd6/0x100 crypto/ahash.c:113
           shash_ahash_update+0x41/0x60 crypto/shash.c:251
           shash_async_update+0xd/0x10 crypto/shash.c:260
           crypto_ahash_update include/crypto/hash.h:539 [inline]
           poly_setkey+0xf6/0x130 crypto/chacha20poly1305.c:337
           poly_init+0x51/0x60 crypto/chacha20poly1305.c:364
           async_done_continue crypto/chacha20poly1305.c:78 [inline]
           poly_genkey_done+0x15/0x30 crypto/chacha20poly1305.c:369
           cryptd_skcipher_complete+0x29/0x70 crypto/cryptd.c:279
           cryptd_skcipher_decrypt+0xcd/0x110 crypto/cryptd.c:339
           cryptd_queue_worker+0x70/0xa0 crypto/cryptd.c:184
           process_one_work+0x1ed/0x420 kernel/workqueue.c:2269
           worker_thread+0x3e/0x3a0 kernel/workqueue.c:2415
           kthread+0x11f/0x140 kernel/kthread.c:255
           ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:352
      
      Fixes: 71ebc4d1 ("crypto: chacha20poly1305 - Add a ChaCha20-Poly1305 AEAD construction, RFC7539")
      Cc: <stable@vger.kernel.org> # v4.2+
      Cc: Martin Willi <martin@strongswan.org>
      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>
      2fd5789c
    • Elena Petrova's avatar
      crypto: arm64/sha2-ce - correct digest for empty data in finup · f8f4776c
      Elena Petrova authored
      commit 6bd934de upstream.
      
      The sha256-ce finup implementation for ARM64 produces wrong digest
      for empty input (len=0). Expected: the actual digest, result: initial
      value of SHA internal state. The error is in sha256_ce_finup:
      for empty data `finalize` will be 1, so the code is relying on
      sha2_ce_transform to make the final round. However, in
      sha256_base_do_update, the block function will not be called when
      len == 0.
      
      Fix it by setting finalize to 0 if data is empty.
      
      Fixes: 03802f6a ("crypto: arm64/sha2-ce - move SHA-224/256 ARMv8 implementation to base layer")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarElena Petrova <lenaptr@google.com>
      Reviewed-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f8f4776c
    • Elena Petrova's avatar
      crypto: arm64/sha1-ce - correct digest for empty data in finup · a14c70b5
      Elena Petrova authored
      commit 1d4aaf16 upstream.
      
      The sha1-ce finup implementation for ARM64 produces wrong digest
      for empty input (len=0). Expected: da39a3ee..., result: 67452301...
      (initial value of SHA internal state). The error is in sha1_ce_finup:
      for empty data `finalize` will be 1, so the code is relying on
      sha1_ce_transform to make the final round. However, in
      sha1_base_do_update, the block function will not be called when
      len == 0.
      
      Fix it by setting finalize to 0 if data is empty.
      
      Fixes: 07eb54d3 ("crypto: arm64/sha1-ce - move SHA-1 ARMv8 implementation to base layer")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarElena Petrova <lenaptr@google.com>
      Reviewed-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a14c70b5
    • Hook, Gary's avatar
      crypto: ccp - Validate the the error value used to index error messages · 8ab50be8
      Hook, Gary authored
      commit 52393d61 upstream.
      
      The error code read from the queue status register is only 6 bits wide,
      but we need to verify its value is within range before indexing the error
      messages.
      
      Fixes: 81422bad ("crypto: ccp - Make syslog errors human-readable")
      Cc: <stable@vger.kernel.org>
      Reported-by: default avatarCfir Cohen <cfir@google.com>
      Signed-off-by: default avatarGary R Hook <gary.hook@amd.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8ab50be8
    • Ard Biesheuvel's avatar
      crypto: caam - limit output IV to CBC to work around CTR mode DMA issue · f976273a
      Ard Biesheuvel authored
      commit ed527b13 upstream.
      
      The CAAM driver currently violates an undocumented and slightly
      controversial requirement imposed by the crypto stack that a buffer
      referred to by the request structure via its virtual address may not
      be modified while any scatterlists passed via the same request
      structure are mapped for inbound DMA.
      
      This may result in errors like
      
        alg: aead: decryption failed on test 1 for gcm_base(ctr-aes-caam,ghash-generic): ret=74
        alg: aead: Failed to load transform for gcm(aes): -2
      
      on non-cache coherent systems, due to the fact that the GCM driver
      passes an IV buffer by virtual address which shares a cacheline with
      the auth_tag buffer passed via a scatterlist, resulting in corruption
      of the auth_tag when the IV is updated while the DMA mapping is live.
      
      Since the IV that is returned to the caller is only valid for CBC mode,
      and given that the in-kernel users of CBC (such as CTS) don't trigger the
      same issue as the GCM driver, let's just disable the output IV generation
      for all modes except CBC for the time being.
      
      Fixes: 854b06f7 ("crypto: caam - properly set IV after {en,de}crypt")
      Cc: Horia Geanta <horia.geanta@nxp.com>
      Cc: Iuliana Prodan <iuliana.prodan@nxp.com>
      Reported-by: default avatarSascha Hauer <s.hauer@pengutronix.de>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Reviewed-by: default avatarHoria Geanta <horia.geanta@nxp.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f976273a
    • Eric Biggers's avatar
      crypto: ghash - fix unaligned memory access in ghash_setkey() · f80432bf
      Eric Biggers authored
      commit 5c6bc4df upstream.
      
      Changing ghash_mod_init() to be subsys_initcall made it start running
      before the alignment fault handler has been installed on ARM.  In kernel
      builds where the keys in the ghash test vectors happened to be
      misaligned in the kernel image, this exposed the longstanding bug that
      ghash_setkey() is incorrectly casting the key buffer (which can have any
      alignment) to be128 for passing to gf128mul_init_4k_lle().
      
      Fix this by memcpy()ing the key to a temporary buffer.
      
      Don't fix it by setting an alignmask on the algorithm instead because
      that would unnecessarily force alignment of the data too.
      
      Fixes: 2cdc6899 ("crypto: ghash - Add GHASH digest algorithm for GCM")
      Reported-by: default avatarPeter Robinson <pbrobinson@gmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Tested-by: default avatarPeter Robinson <pbrobinson@gmail.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f80432bf
    • Finn Thain's avatar
      scsi: mac_scsi: Fix pseudo DMA implementation, take 2 · dba955f2
      Finn Thain authored
      commit 78ff751f upstream.
      
      A system bus error during a PDMA transfer can mess up the calculation of
      the transfer residual (the PDMA handshaking hardware lacks a byte
      counter). This results in data corruption.
      
      The algorithm in this patch anticipates a bus error by starting each
      transfer with a MOVE.B instruction. If a bus error is caught the transfer
      will be retried. If a bus error is caught later in the transfer (for a
      MOVE.W instruction) the transfer gets failed and subsequent requests for
      that target will use PIO instead of PDMA.
      
      This avoids the "!REQ and !ACK" error so the severity level of that message
      is reduced to KERN_DEBUG.
      
      Cc: Michael Schmitz <schmitzmic@gmail.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: stable@vger.kernel.org # v4.14+
      Fixes: 3a0f64bf ("mac_scsi: Fix pseudo DMA implementation")
      Signed-off-by: default avatarFinn Thain <fthain@telegraphics.com.au>
      Reported-by: default avatarChris Jones <chris@martin-jones.com>
      Tested-by: default avatarStan Johnson <userm57@yahoo.com>
      Tested-by: default avatarMichael Schmitz <schmitzmic@gmail.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dba955f2
    • Finn Thain's avatar
      scsi: mac_scsi: Increase PIO/PDMA transfer length threshold · c8013794
      Finn Thain authored
      commit 7398cee4 upstream.
      
      Some targets introduce delays when handshaking the response to certain
      commands. For example, a disk may send a 96-byte response to an INQUIRY
      command (or a 24-byte response to a MODE SENSE command) too slowly.
      
      Apparently the first 12 or 14 bytes are handshaked okay but then the system
      bus error timeout is reached while transferring the next word.
      
      Since the scsi bus phase hasn't changed, the driver then sets the target
      borken flag to prevent further PDMA transfers. The driver also logs the
      warning, "switching to slow handshake".
      
      Raise the PDMA threshold to 512 bytes so that PIO transfers will be used
      for these commands. This default is sufficiently low that PDMA will still
      be used for READ and WRITE commands.
      
      The existing threshold (16 bytes) was chosen more or less at random.
      However, best performance requires the threshold to be as low as possible.
      Those systems that don't need the PIO workaround at all may benefit from
      mac_scsi.setup_use_pdma=1
      
      Cc: Michael Schmitz <schmitzmic@gmail.com>
      Cc: stable@vger.kernel.org # v4.14+
      Fixes: 3a0f64bf ("mac_scsi: Fix pseudo DMA implementation")
      Signed-off-by: default avatarFinn Thain <fthain@telegraphics.com.au>
      Tested-by: default avatarStan Johnson <userm57@yahoo.com>
      Tested-by: default avatarMichael Schmitz <schmitzmic@gmail.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c8013794
    • Shivasharan S's avatar
      scsi: megaraid_sas: Fix calculation of target ID · 7c266d7a
      Shivasharan S authored
      commit c8f96df5 upstream.
      
      In megasas_get_target_prop(), driver is incorrectly calculating the target
      ID for devices with channel 1 and 3.  Due to this, firmware will either
      fail the command (if there is no device with the target id sent from
      driver) or could return the properties for a target which was not
      intended.  Devices could end up with the wrong queue depth due to this.
      
      Fix target id calculation for channel 1 and 3.
      
      Fixes: 96188a89 ("scsi: megaraid_sas: NVME interface target prop added")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarShivasharan S <shivasharan.srikanteshwara@broadcom.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7c266d7a
    • Benjamin Block's avatar
      scsi: zfcp: fix request object use-after-free in send path causing wrong traces · 3f0548a6
      Benjamin Block authored
      commit 106d45f3 upstream.
      
      When tracing instances where we open and close WKA ports, we also pass the
      request-ID of the respective FSF command.
      
      But after successfully sending the FSF command we must not use the
      request-object anymore, as this might result in an use-after-free (see
      "zfcp: fix request object use-after-free in send path causing seqno
      errors" ).
      
      To fix this add a new variable that caches the request-ID before sending
      the request. This won't change during the hand-off to the FCP channel,
      and so it's safe to trace this cached request-ID later, instead of using
      the request object.
      Signed-off-by: default avatarBenjamin Block <bblock@linux.ibm.com>
      Fixes: d27a7cb9 ("zfcp: trace on request for open and close of WKA port")
      Cc: <stable@vger.kernel.org> #2.6.38+
      Reviewed-by: default avatarSteffen Maier <maier@linux.ibm.com>
      Reviewed-by: default avatarJens Remus <jremus@linux.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3f0548a6
    • Benjamin Block's avatar
      scsi: zfcp: fix request object use-after-free in send path causing seqno errors · 30724ade
      Benjamin Block authored
      commit b76becde upstream.
      
      With a recent change to our send path for FSF commands we introduced a
      possible use-after-free of request-objects, that might further lead to
      zfcp crafting bad requests, which the FCP channel correctly complains
      about with an error (FSF_PROT_SEQ_NUMB_ERROR). This error is then handled
      by an adapter-wide recovery.
      
      The following sequence illustrates the possible use-after-free:
      
          Send Path:
      
              int zfcp_fsf_open_port(struct zfcp_erp_action *erp_action)
              {
                      struct zfcp_fsf_req *req;
                      ...
                      spin_lock_irq(&qdio->req_q_lock);
              //                     ^^^^^^^^^^^^^^^^
              //                     protects QDIO queue during sending
                      ...
                      req = zfcp_fsf_req_create(qdio,
                                                FSF_QTCB_OPEN_PORT_WITH_DID,
                                                SBAL_SFLAGS0_TYPE_READ,
                                                qdio->adapter->pool.erp_req);
              //            ^^^^^^^^^^^^^^^^^^^
              //            allocation of the request-object
                      ...
                      retval = zfcp_fsf_req_send(req);
                      ...
                      spin_unlock_irq(&qdio->req_q_lock);
                      return retval;
              }
      
              static int zfcp_fsf_req_send(struct zfcp_fsf_req *req)
              {
                      struct zfcp_adapter *adapter = req->adapter;
                      struct zfcp_qdio *qdio = adapter->qdio;
                      ...
                      zfcp_reqlist_add(adapter->req_list, req);
              //      ^^^^^^^^^^^^^^^^
              //      add request to our driver-internal hash-table for tracking
              //      (protected by separate lock req_list->lock)
                      ...
                      if (zfcp_qdio_send(qdio, &req->qdio_req)) {
              //          ^^^^^^^^^^^^^^
              //          hand-off the request to FCP channel;
              //          the request can complete at any point now
                              ...
                      }
      
                      /* Don't increase for unsolicited status */
                      if (!zfcp_fsf_req_is_status_read_buffer(req))
              //           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
              //           possible use-after-free
                              adapter->fsf_req_seq_no++;
              //                       ^^^^^^^^^^^^^^^^
              //                       because of the use-after-free we might
              //                       miss this accounting, and as follow-up
              //                       this results in the FCP channel error
              //                       FSF_PROT_SEQ_NUMB_ERROR
                      adapter->req_no++;
      
                      return 0;
              }
      
              static inline bool
              zfcp_fsf_req_is_status_read_buffer(struct zfcp_fsf_req *req)
              {
                      return req->qtcb == NULL;
              //             ^^^^^^^^^
              //             possible use-after-free
              }
      
          Response Path:
      
              void zfcp_fsf_reqid_check(struct zfcp_qdio *qdio, int sbal_idx)
              {
                      ...
                      struct zfcp_fsf_req *fsf_req;
                      ...
                      for (idx = 0; idx < QDIO_MAX_ELEMENTS_PER_BUFFER; idx++) {
                              ...
                              fsf_req = zfcp_reqlist_find_rm(adapter->req_list,
                                                             req_id);
              //                        ^^^^^^^^^^^^^^^^^^^^
              //                        remove request from our driver-internal
              //                        hash-table (lock req_list->lock)
                              ...
                              zfcp_fsf_req_complete(fsf_req);
                      }
              }
      
              static void zfcp_fsf_req_complete(struct zfcp_fsf_req *req)
              {
                      ...
                      if (likely(req->status & ZFCP_STATUS_FSFREQ_CLEANUP))
                              zfcp_fsf_req_free(req);
              //              ^^^^^^^^^^^^^^^^^
              //              free memory for request-object
                      else
                              complete(&req->completion);
              //              ^^^^^^^^
              //              completion notification for code-paths that wait
              //              synchronous for the completion of the request; in
              //              those the memory is freed separately
              }
      
      The result of the use-after-free only affects the send path, and can not
      lead to any data corruption. In case we miss the sequence-number
      accounting, because the memory was already re-purposed, the next FSF
      command will fail with said FCP channel error, and we will recover the
      whole adapter. This causes no additional errors, but it slows down
      traffic.  There is a slight chance of the same thing happen again
      recursively after the adapter recovery, but so far this has not been seen.
      
      This was seen under z/VM, where the send path might run on a virtual CPU
      that gets scheduled away by z/VM, while the return path might still run,
      and so create the necessary timing. Running with KASAN can also slow down
      the kernel sufficiently to run into this user-after-free, and then see the
      report by KASAN.
      
      To fix this, simply pull the test for the sequence-number accounting in
      front of the hand-off to the FCP channel (this information doesn't change
      during hand-off), but leave the sequence-number accounting itself where it
      is.
      
      To make future regressions of the same kind less likely, add comments to
      all closely related code-paths.
      Signed-off-by: default avatarBenjamin Block <bblock@linux.ibm.com>
      Fixes: f9eca022 ("scsi: zfcp: drop duplicate fsf_command from zfcp_fsf_req which is also in QTCB header")
      Cc: <stable@vger.kernel.org> #5.0+
      Reviewed-by: default avatarSteffen Maier <maier@linux.ibm.com>
      Reviewed-by: default avatarJens Remus <jremus@linux.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      30724ade
    • Damien Le Moal's avatar
      scsi: sd_zbc: Fix compilation warning · 7b10d7e3
      Damien Le Moal authored
      commit 0cdc5858 upstream.
      
      kbuild test robot gets the following compilation warning using gcc 7.4
      cross compilation for c6x (GCC_VERSION=7.4.0 make.cross ARCH=c6x).
      
         In file included from include/asm-generic/bug.h:18:0,
                          from arch/c6x/include/asm/bug.h:12,
                          from include/linux/bug.h:5,
                          from include/linux/thread_info.h:12,
                          from include/asm-generic/current.h:5,
                          from ./arch/c6x/include/generated/asm/current.h:1,
                          from include/linux/sched.h:12,
                          from include/linux/blkdev.h:5,
                          from drivers//scsi/sd_zbc.c:11:
         drivers//scsi/sd_zbc.c: In function 'sd_zbc_read_zones':
      >> include/linux/kernel.h:62:48: warning: 'zone_blocks' may be used
         uninitialized in this function [-Wmaybe-uninitialized]
          #define __round_mask(x, y) ((__typeof__(x))((y)-1))
                                                         ^
         drivers//scsi/sd_zbc.c:464:6: note: 'zone_blocks' was declared here
           u32 zone_blocks;
               ^~~~~~~~~~~
      
      This is a false-positive report. The variable zone_blocks is always
      initialized in sd_zbc_check_zones() before use. It is not initialized
      only and only if sd_zbc_check_zones() fails.
      
      Avoid this warning by initializing the zone_blocks variable to 0.
      
      Fixes: 5f832a39 ("scsi: sd_zbc: Fix sd_zbc_check_zones() error checks")
      Cc: Stable <stable@vger.kernel.org>
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@wdc.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7b10d7e3
    • Ming Lei's avatar
      scsi: core: Fix race on creating sense cache · f263fbd2
      Ming Lei authored
      commit f9b0530f upstream.
      
      When scsi_init_sense_cache(host) is called concurrently from different
      hosts, each code path may find that no cache has been created and
      allocate a new one. The lack of locking can lead to potentially
      overriding a cache allocated by a different host.
      
      Fix the issue by moving 'mutex_lock(&scsi_sense_cache_mutex)' before
      scsi_select_sense_cache().
      
      Fixes: 0a6ac4ee ("scsi: respect unchecked_isa_dma for blk-mq")
      Cc: Stable <stable@vger.kernel.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Hannes Reinecke <hare@suse.com>
      Cc: Ewan D. Milne <emilne@redhat.com>
      Signed-off-by: default avatarMing Lei <ming.lei@redhat.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f263fbd2
    • Finn Thain's avatar
      Revert "scsi: ncr5380: Increase register polling limit" · 38fd8cec
      Finn Thain authored
      commit 25fcf94a upstream.
      
      This reverts commit 4822827a.
      
      The purpose of that commit was to suppress a timeout warning message which
      appeared to be caused by target latency. But suppressing the warning is
      undesirable as the warning may indicate a messed up transfer count.
      
      Another problem with that commit is that 15 ms is too long to keep
      interrupts disabled as interrupt latency can cause system clock drift and
      other problems.
      
      Cc: Michael Schmitz <schmitzmic@gmail.com>
      Cc: stable@vger.kernel.org
      Fixes: 4822827a ("scsi: ncr5380: Increase register polling limit")
      Signed-off-by: default avatarFinn Thain <fthain@telegraphics.com.au>
      Tested-by: default avatarStan Johnson <userm57@yahoo.com>
      Tested-by: default avatarMichael Schmitz <schmitzmic@gmail.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      38fd8cec
    • Finn Thain's avatar
      scsi: NCR5380: Handle PDMA failure reliably · 3e7b99aa
      Finn Thain authored
      commit f9dfed1c upstream.
      
      A PDMA error is handled in the core driver by setting the device's 'borken'
      flag and aborting the command. Unfortunately, do_abort() is not
      dependable. Perform a SCSI bus reset instead, to make sure that the command
      fails and gets retried.
      
      Cc: Michael Schmitz <schmitzmic@gmail.com>
      Cc: stable@vger.kernel.org # v4.20+
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarFinn Thain <fthain@telegraphics.com.au>
      Tested-by: default avatarStan Johnson <userm57@yahoo.com>
      Tested-by: default avatarMichael Schmitz <schmitzmic@gmail.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3e7b99aa
    • Finn Thain's avatar
      scsi: NCR5380: Always re-enable reselection interrupt · 45749b15
      Finn Thain authored
      commit 57f31326 upstream.
      
      The reselection interrupt gets disabled during selection and must be
      re-enabled when hostdata->connected becomes NULL. If it isn't re-enabled a
      disconnected command may time-out or the target may wedge the bus while
      trying to reselect the host. This can happen after a command is aborted.
      
      Fix this by enabling the reselection interrupt in NCR5380_main() after
      calls to NCR5380_select() and NCR5380_information_transfer() return.
      
      Cc: Michael Schmitz <schmitzmic@gmail.com>
      Cc: stable@vger.kernel.org # v4.9+
      Fixes: 8b00c3d5 ("ncr5380: Implement new eh_abort_handler")
      Signed-off-by: default avatarFinn Thain <fthain@telegraphics.com.au>
      Tested-by: default avatarStan Johnson <userm57@yahoo.com>
      Tested-by: default avatarMichael Schmitz <schmitzmic@gmail.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      45749b15
    • Juergen Gross's avatar
      xen: let alloc_xenballooned_pages() fail if not enough memory free · 1548da48
      Juergen Gross authored
      commit a1078e82 upstream.
      
      Instead of trying to allocate pages with GFP_USER in
      add_ballooned_pages() check the available free memory via
      si_mem_available(). GFP_USER is far less limiting memory exhaustion
      than the test via si_mem_available().
      
      This will avoid dom0 running out of memory due to excessive foreign
      page mappings especially on ARM and on x86 in PVH mode, as those don't
      have a pre-ballooned area which can be used for foreign mappings.
      
      As the normal ballooning suffers from the same problem don't balloon
      down more than si_mem_available() pages in one iteration. At the same
      time limit the default maximum number of retries.
      
      This is part of XSA-300.
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1548da48
    • Denis Efremov's avatar
      floppy: fix out-of-bounds read in copy_buffer · 0a67173b
      Denis Efremov authored
      [ Upstream commit da99466a ]
      
      This fixes a global out-of-bounds read access in the copy_buffer
      function of the floppy driver.
      
      The FDDEFPRM ioctl allows one to set the geometry of a disk.  The sect
      and head fields (unsigned int) of the floppy_drive structure are used to
      compute the max_sector (int) in the make_raw_rw_request function.  It is
      possible to overflow the max_sector.  Next, max_sector is passed to the
      copy_buffer function and used in one of the memcpy calls.
      
      An unprivileged user could trigger the bug if the device is accessible,
      but requires a floppy disk to be inserted.
      
      The patch adds the check for the .sect * .head multiplication for not
      overflowing in the set_geometry function.
      
      The bug was found by syzkaller.
      Signed-off-by: default avatarDenis Efremov <efremov@ispras.ru>
      Tested-by: default avatarWilly Tarreau <w@1wt.eu>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      0a67173b
    • Denis Efremov's avatar
      floppy: fix invalid pointer dereference in drive_name · deaa1395
      Denis Efremov authored
      [ Upstream commit 9b04609b ]
      
      This fixes the invalid pointer dereference in the drive_name function of
      the floppy driver.
      
      The native_format field of the struct floppy_drive_params is used as
      floppy_type array index in the drive_name function.  Thus, the field
      should be checked the same way as the autodetect field.
      
      To trigger the bug, one could use a value out of range and set the drive
      parameters with the FDSETDRVPRM ioctl.  Next, FDGETDRVTYP ioctl should
      be used to call the drive_name.  A floppy disk is not required to be
      inserted.
      
      CAP_SYS_ADMIN is required to call FDSETDRVPRM.
      
      The patch adds the check for a value of the native_format field to be in
      the '0 <= x < ARRAY_SIZE(floppy_type)' range of the floppy_type array
      indices.
      
      The bug was found by syzkaller.
      Signed-off-by: default avatarDenis Efremov <efremov@ispras.ru>
      Tested-by: default avatarWilly Tarreau <w@1wt.eu>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      deaa1395
    • Denis Efremov's avatar
      floppy: fix out-of-bounds read in next_valid_format · acf80219
      Denis Efremov authored
      [ Upstream commit 5635f897 ]
      
      This fixes a global out-of-bounds read access in the next_valid_format
      function of the floppy driver.
      
      The values from autodetect field of the struct floppy_drive_params are
      used as indices for the floppy_type array in the next_valid_format
      function 'floppy_type[DP->autodetect[probed_format]].sect'.
      
      To trigger the bug, one could use a value out of range and set the drive
      parameters with the FDSETDRVPRM ioctl.  A floppy disk is not required to
      be inserted.
      
      CAP_SYS_ADMIN is required to call FDSETDRVPRM.
      
      The patch adds the check for values of the autodetect field to be in the
      '0 <= x < ARRAY_SIZE(floppy_type)' range of the floppy_type array indices.
      
      The bug was found by syzkaller.
      Signed-off-by: default avatarDenis Efremov <efremov@ispras.ru>
      Tested-by: default avatarWilly Tarreau <w@1wt.eu>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      acf80219
    • Denis Efremov's avatar
      floppy: fix div-by-zero in setup_format_params · a2bd7b41
      Denis Efremov authored
      [ Upstream commit f3554aeb ]
      
      This fixes a divide by zero error in the setup_format_params function of
      the floppy driver.
      
      Two consecutive ioctls can trigger the bug: The first one should set the
      drive geometry with such .sect and .rate values for the F_SECT_PER_TRACK
      to become zero.  Next, the floppy format operation should be called.
      
      A floppy disk is not required to be inserted.  An unprivileged user
      could trigger the bug if the device is accessible.
      
      The patch checks F_SECT_PER_TRACK for a non-zero value in the
      set_geometry function.  The proper check should involve a reasonable
      upper limit for the .sect and .rate fields, but it could change the
      UAPI.
      
      The patch also checks F_SECT_PER_TRACK in the setup_format_params, and
      cancels the formatting operation in case of zero.
      
      The bug was found by syzkaller.
      Signed-off-by: default avatarDenis Efremov <efremov@ispras.ru>
      Tested-by: default avatarWilly Tarreau <w@1wt.eu>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a2bd7b41
    • Andrii Nakryiko's avatar
      libbpf: fix another GCC8 warning for strncpy · ae01e55f
      Andrii Nakryiko authored
      [ Upstream commit 763ff0e7 ]
      
      Similar issue was fixed in cdfc7f88 ("libbpf: fix GCC8 warning for
      strncpy") already. This one was missed. Fixing now.
      
      Cc: Magnus Karlsson <magnus.karlsson@intel.com>
      Signed-off-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Acked-by: default avatarMagnus Karlsson <magnus.karlsson@intel.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ae01e55f
    • Dennis Zhou's avatar
      blk-iolatency: fix STS_AGAIN handling · 9a3aaff7
      Dennis Zhou authored
      [ Upstream commit c9b3007f ]
      
      The iolatency controller is based on rq_qos. It increments on
      rq_qos_throttle() and decrements on either rq_qos_cleanup() or
      rq_qos_done_bio(). a3fb01ba fixes the double accounting issue where
      blk_mq_make_request() may call both rq_qos_cleanup() and
      rq_qos_done_bio() on REQ_NO_WAIT. So checking STS_AGAIN prevents the
      double decrement.
      
      The above works upstream as the only way we can get STS_AGAIN is from
      blk_mq_get_request() failing. The STS_AGAIN handling isn't a real
      problem as bio_endio() skipping only happens on reserved tag allocation
      failures which can only be caused by driver bugs and already triggers
      WARN.
      
      However, the fix creates a not so great dependency on how STS_AGAIN can
      be propagated. Internally, we (Facebook) carry a patch that kills read
      ahead if a cgroup is io congested or a fatal signal is pending. This
      combined with chained bios progagate their bi_status to the parent is
      not already set can can cause the parent bio to not clean up properly
      even though it was successful. This consequently leaks the inflight
      counter and can hang all IOs under that blkg.
      
      To nip the adverse interaction early, this removes the rq_qos_cleanup()
      callback in iolatency in favor of cleaning up always on the
      rq_qos_done_bio() path.
      
      Fixes: a3fb01ba ("blk-iolatency: only account submitted bios")
      Debugged-by: default avatarTejun Heo <tj@kernel.org>
      Debugged-by: default avatarJosef Bacik <josef@toxicpanda.com>
      Signed-off-by: default avatarDennis Zhou <dennis@kernel.org>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9a3aaff7
    • Colin Ian King's avatar
      iavf: fix dereference of null rx_buffer pointer · c05dbbdd
      Colin Ian King authored
      [ Upstream commit 9fe06a51 ]
      
      A recent commit efa14c39 ("iavf: allow null RX descriptors") added
      a null pointer sanity check on rx_buffer, however, rx_buffer is being
      dereferenced before that check, which implies a null pointer dereference
      bug can potentially occur.  Fix this by only dereferencing rx_buffer
      until after the null pointer check.
      
      Addresses-Coverity: ("Dereference before null check")
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c05dbbdd
    • Huazhong Tan's avatar
      net: hns3: fix __QUEUE_STATE_STACK_XOFF not cleared issue · 5be48072
      Huazhong Tan authored
      [ Upstream commit f96315f2 ]
      
      When change MTU or other operations, which just calling .reset_notify
      to do HNAE3_DOWN_CLIENT and HNAE3_UP_CLIENT, then
      the netdev_tx_reset_queue() in the hns3_clear_all_ring() will be
      ignored. So the dev_watchdog() may misdiagnose a TX timeout.
      
      This patch separates netdev_tx_reset_queue() from
      hns3_clear_all_ring(), and unifies hns3_clear_all_ring() and
      hns3_force_clear_all_ring into one, since they are doing
      similar things.
      
      Fixes: 3a30964a ("net: hns3: delay ring buffer clearing during reset")
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5be48072
    • Josua Mayer's avatar
      net: mvmdio: defer probe of orion-mdio if a clock is not ready · 067471e8
      Josua Mayer authored
      [ Upstream commit 433a06d7 ]
      
      Defer probing of the orion-mdio interface when getting a clock returns
      EPROBE_DEFER. This avoids locking up the Armada 8k SoC when mdio is used
      before all clocks have been enabled.
      Signed-off-by: default avatarJosua Mayer <josua@solid-run.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      067471e8
    • Ilya Maximets's avatar
      xdp: fix race on generic receive path · fd7c22ba
      Ilya Maximets authored
      [ Upstream commit bf0bdd13 ]
      
      Unlike driver mode, generic xdp receive could be triggered
      by different threads on different CPU cores at the same time
      leading to the fill and rx queue breakage. For example, this
      could happen while sending packets from two processes to the
      first interface of veth pair while the second part of it is
      open with AF_XDP socket.
      
      Need to take a lock for each generic receive to avoid race.
      
      Fixes: c497176c ("xsk: add Rx receive functions and poll support")
      Signed-off-by: default avatarIlya Maximets <i.maximets@samsung.com>
      Acked-by: default avatarMagnus Karlsson <magnus.karlsson@intel.com>
      Tested-by: default avatarWilliam Tu <u9012063@gmail.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      fd7c22ba
    • Taehee Yoo's avatar
      gtp: fix use-after-free in gtp_newlink() · 29af1ae8
      Taehee Yoo authored
      [ Upstream commit a2bed907 ]
      
      Current gtp_newlink() could be called after unregister_pernet_subsys().
      gtp_newlink() uses gtp_net but it can be destroyed by
      unregister_pernet_subsys().
      So unregister_pernet_subsys() should be called after
      rtnl_link_unregister().
      
      Test commands:
         #SHELL 1
         while :
         do
      	   for i in {1..5}
      	   do
      		./gtp-link add gtp$i &
      	   done
      	   killall gtp-link
         done
      
         #SHELL 2
         while :
         do
      	modprobe -rv gtp
         done
      
      Splat looks like:
      [  753.176631] BUG: KASAN: use-after-free in gtp_newlink+0x9b4/0xa5c [gtp]
      [  753.177722] Read of size 8 at addr ffff8880d48f2458 by task gtp-link/7126
      [  753.179082] CPU: 0 PID: 7126 Comm: gtp-link Tainted: G        W         5.2.0-rc6+ #50
      [  753.185801] Call Trace:
      [  753.186264]  dump_stack+0x7c/0xbb
      [  753.186863]  ? gtp_newlink+0x9b4/0xa5c [gtp]
      [  753.187583]  print_address_description+0xc7/0x240
      [  753.188382]  ? gtp_newlink+0x9b4/0xa5c [gtp]
      [  753.189097]  ? gtp_newlink+0x9b4/0xa5c [gtp]
      [  753.189846]  __kasan_report+0x12a/0x16f
      [  753.190542]  ? gtp_newlink+0x9b4/0xa5c [gtp]
      [  753.191298]  kasan_report+0xe/0x20
      [  753.191893]  gtp_newlink+0x9b4/0xa5c [gtp]
      [  753.192580]  ? __netlink_ns_capable+0xc3/0xf0
      [  753.193370]  __rtnl_newlink+0xb9f/0x11b0
      [ ... ]
      [  753.241201] Allocated by task 7186:
      [  753.241844]  save_stack+0x19/0x80
      [  753.242399]  __kasan_kmalloc.constprop.3+0xa0/0xd0
      [  753.243192]  __kmalloc+0x13e/0x300
      [  753.243764]  ops_init+0xd6/0x350
      [  753.244314]  register_pernet_operations+0x249/0x6f0
      [ ... ]
      [  753.251770] Freed by task 7178:
      [  753.252288]  save_stack+0x19/0x80
      [  753.252833]  __kasan_slab_free+0x111/0x150
      [  753.253962]  kfree+0xc7/0x280
      [  753.254509]  ops_free_list.part.11+0x1c4/0x2d0
      [  753.255241]  unregister_pernet_operations+0x262/0x390
      [ ... ]
      [  753.285883] list_add corruption. next->prev should be prev (ffff8880d48f2458), but was ffff8880d497d878. (next.
      [  753.287241] ------------[ cut here ]------------
      [  753.287794] kernel BUG at lib/list_debug.c:25!
      [  753.288364] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
      [  753.289099] CPU: 0 PID: 7126 Comm: gtp-link Tainted: G    B   W         5.2.0-rc6+ #50
      [  753.291036] RIP: 0010:__list_add_valid+0x74/0xd0
      [  753.291589] Code: 48 39 da 75 27 48 39 f5 74 36 48 39 dd 74 31 48 83 c4 08 b8 01 00 00 00 5b 5d c3 48 89 d9 48b
      [  753.293779] RSP: 0018:ffff8880cae8f398 EFLAGS: 00010286
      [  753.294401] RAX: 0000000000000075 RBX: ffff8880d497d878 RCX: 0000000000000000
      [  753.296260] RDX: 0000000000000075 RSI: 0000000000000008 RDI: ffffed10195d1e69
      [  753.297070] RBP: ffff8880cd250ae0 R08: ffffed101b4bff21 R09: ffffed101b4bff21
      [  753.297899] R10: 0000000000000001 R11: ffffed101b4bff20 R12: ffff8880d497d878
      [  753.298703] R13: 0000000000000000 R14: ffff8880cd250ae0 R15: ffff8880d48f2458
      [  753.299564] FS:  00007f5f79805740(0000) GS:ffff8880da400000(0000) knlGS:0000000000000000
      [  753.300533] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  753.301231] CR2: 00007fe8c7ef4f10 CR3: 00000000b71a6006 CR4: 00000000000606f0
      [  753.302183] Call Trace:
      [  753.302530]  gtp_newlink+0x5f6/0xa5c [gtp]
      [  753.303037]  ? __netlink_ns_capable+0xc3/0xf0
      [  753.303576]  __rtnl_newlink+0xb9f/0x11b0
      [  753.304092]  ? rtnl_link_unregister+0x230/0x230
      
      Fixes: 459aa660 ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)")
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      29af1ae8
    • Taehee Yoo's avatar
      gtp: fix use-after-free in gtp_encap_destroy() · 8b9673c2
      Taehee Yoo authored
      [ Upstream commit 1788b856 ]
      
      gtp_encap_destroy() is called twice.
      1. When interface is deleted.
      2. When udp socket is destroyed.
      either gtp->sk0 or gtp->sk1u could be freed by sock_put() in
      gtp_encap_destroy(). so, when gtp_encap_destroy() is called again,
      it would uses freed sk pointer.
      
      patch makes gtp_encap_destroy() to set either gtp->sk0 or gtp->sk1u to
      null. in addition, both gtp->sk0 and gtp->sk1u pointer are protected
      by rtnl_lock. so, rtnl_lock() is added.
      
      Test command:
         gtp-link add gtp1 &
         killall gtp-link
         ip link del gtp1
      
      Splat looks like:
      [   83.182767] BUG: KASAN: use-after-free in __lock_acquire+0x3a20/0x46a0
      [   83.184128] Read of size 8 at addr ffff8880cc7d5360 by task ip/1008
      [   83.185567] CPU: 1 PID: 1008 Comm: ip Not tainted 5.2.0-rc6+ #50
      [   83.188469] Call Trace:
      [ ... ]
      [   83.200126]  lock_acquire+0x141/0x380
      [   83.200575]  ? lock_sock_nested+0x3a/0xf0
      [   83.201069]  _raw_spin_lock_bh+0x38/0x70
      [   83.201551]  ? lock_sock_nested+0x3a/0xf0
      [   83.202044]  lock_sock_nested+0x3a/0xf0
      [   83.202520]  gtp_encap_destroy+0x18/0xe0 [gtp]
      [   83.203065]  gtp_encap_disable.isra.14+0x13/0x50 [gtp]
      [   83.203687]  gtp_dellink+0x56/0x170 [gtp]
      [   83.204190]  rtnl_delete_link+0xb4/0x100
      [ ... ]
      [   83.236513] Allocated by task 976:
      [   83.236925]  save_stack+0x19/0x80
      [   83.237332]  __kasan_kmalloc.constprop.3+0xa0/0xd0
      [   83.237894]  kmem_cache_alloc+0xd8/0x280
      [   83.238360]  sk_prot_alloc.isra.42+0x50/0x200
      [   83.238874]  sk_alloc+0x32/0x940
      [   83.239264]  inet_create+0x283/0xc20
      [   83.239684]  __sock_create+0x2dd/0x540
      [   83.240136]  __sys_socket+0xca/0x1a0
      [   83.240550]  __x64_sys_socket+0x6f/0xb0
      [   83.240998]  do_syscall_64+0x9c/0x450
      [   83.241466]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [   83.242061]
      [   83.242249] Freed by task 0:
      [   83.242616]  save_stack+0x19/0x80
      [   83.243013]  __kasan_slab_free+0x111/0x150
      [   83.243498]  kmem_cache_free+0x89/0x250
      [   83.244444]  __sk_destruct+0x38f/0x5a0
      [   83.245366]  rcu_core+0x7e9/0x1c20
      [   83.245766]  __do_softirq+0x213/0x8fa
      
      Fixes: 1e3a3abd ("gtp: make GTP sockets in gtp_newlink optional")
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8b9673c2
    • Taehee Yoo's avatar
      gtp: fix Illegal context switch in RCU read-side critical section. · 1ba3bba8
      Taehee Yoo authored
      [ Upstream commit 3f167e19 ]
      
      ipv4_pdp_add() is called in RCU read-side critical section.
      So GFP_KERNEL should not be used in the function.
      This patch make ipv4_pdp_add() to use GFP_ATOMIC instead of GFP_KERNEL.
      
      Test commands:
      gtp-link add gtp1 &
      gtp-tunnel add gtp1 v1 100 200 1.1.1.1 2.2.2.2
      
      Splat looks like:
      [  130.618881] =============================
      [  130.626382] WARNING: suspicious RCU usage
      [  130.626994] 5.2.0-rc6+ #50 Not tainted
      [  130.627622] -----------------------------
      [  130.628223] ./include/linux/rcupdate.h:266 Illegal context switch in RCU read-side critical section!
      [  130.629684]
      [  130.629684] other info that might help us debug this:
      [  130.629684]
      [  130.631022]
      [  130.631022] rcu_scheduler_active = 2, debug_locks = 1
      [  130.632136] 4 locks held by gtp-tunnel/1025:
      [  130.632925]  #0: 000000002b93c8b7 (cb_lock){++++}, at: genl_rcv+0x15/0x40
      [  130.634159]  #1: 00000000f17bc999 (genl_mutex){+.+.}, at: genl_rcv_msg+0xfb/0x130
      [  130.635487]  #2: 00000000c644ed8e (rtnl_mutex){+.+.}, at: gtp_genl_new_pdp+0x18c/0x1150 [gtp]
      [  130.636936]  #3: 0000000007a1cde7 (rcu_read_lock){....}, at: gtp_genl_new_pdp+0x187/0x1150 [gtp]
      [  130.638348]
      [  130.638348] stack backtrace:
      [  130.639062] CPU: 1 PID: 1025 Comm: gtp-tunnel Not tainted 5.2.0-rc6+ #50
      [  130.641318] Call Trace:
      [  130.641707]  dump_stack+0x7c/0xbb
      [  130.642252]  ___might_sleep+0x2c0/0x3b0
      [  130.642862]  kmem_cache_alloc_trace+0x1cd/0x2b0
      [  130.643591]  gtp_genl_new_pdp+0x6c5/0x1150 [gtp]
      [  130.644371]  genl_family_rcv_msg+0x63a/0x1030
      [  130.645074]  ? mutex_lock_io_nested+0x1090/0x1090
      [  130.645845]  ? genl_unregister_family+0x630/0x630
      [  130.646592]  ? debug_show_all_locks+0x2d0/0x2d0
      [  130.647293]  ? check_flags.part.40+0x440/0x440
      [  130.648099]  genl_rcv_msg+0xa3/0x130
      [ ... ]
      
      Fixes: 459aa660 ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)")
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1ba3bba8
    • Taehee Yoo's avatar
      gtp: fix suspicious RCU usage · bf75202d
      Taehee Yoo authored
      [ Upstream commit e198987e ]
      
      gtp_encap_enable_socket() and gtp_encap_destroy() are not protected
      by rcu_read_lock(). and it's not safe to write sk->sk_user_data.
      This patch make these functions to use lock_sock() instead of
      rcu_dereference_sk_user_data().
      
      Test commands:
          gtp-link add gtp1
      
      Splat looks like:
      [   83.238315] =============================
      [   83.239127] WARNING: suspicious RCU usage
      [   83.239702] 5.2.0-rc6+ #49 Not tainted
      [   83.240268] -----------------------------
      [   83.241205] drivers/net/gtp.c:799 suspicious rcu_dereference_check() usage!
      [   83.243828]
      [   83.243828] other info that might help us debug this:
      [   83.243828]
      [   83.246325]
      [   83.246325] rcu_scheduler_active = 2, debug_locks = 1
      [   83.247314] 1 lock held by gtp-link/1008:
      [   83.248523]  #0: 0000000017772c7f (rtnl_mutex){+.+.}, at: __rtnl_newlink+0x5f5/0x11b0
      [   83.251503]
      [   83.251503] stack backtrace:
      [   83.252173] CPU: 0 PID: 1008 Comm: gtp-link Not tainted 5.2.0-rc6+ #49
      [   83.253271] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [   83.254562] Call Trace:
      [   83.254995]  dump_stack+0x7c/0xbb
      [   83.255567]  gtp_encap_enable_socket+0x2df/0x360 [gtp]
      [   83.256415]  ? gtp_find_dev+0x1a0/0x1a0 [gtp]
      [   83.257161]  ? memset+0x1f/0x40
      [   83.257843]  gtp_newlink+0x90/0xa21 [gtp]
      [   83.258497]  ? __netlink_ns_capable+0xc3/0xf0
      [   83.259260]  __rtnl_newlink+0xb9f/0x11b0
      [   83.260022]  ? rtnl_link_unregister+0x230/0x230
      [ ... ]
      
      Fixes: 1e3a3abd ("gtp: make GTP sockets in gtp_newlink optional")
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      bf75202d