1. 26 7月, 2019 40 次提交
    • C
      Revert "bcache: set CACHE_SET_IO_DISABLE in bch_cached_dev_error()" · 58169c18
      Coly Li 提交于
      commit 695277f16b3a102fcc22c97fdf2de77c7b19f0b3 upstream.
      
      This reverts commit 6147305c.
      
      Although this patch helps the failed bcache device to stop faster when
      too many I/O errors detected on corresponding cached device, setting
      CACHE_SET_IO_DISABLE bit to cache set c->flags was not a good idea. This
      operation will disable all I/Os on cache set, which means other attached
      bcache devices won't work neither.
      
      Without this patch, the failed bcache device can also be stopped
      eventually if internal I/O accomplished (e.g. writeback). Therefore here
      I revert it.
      
      Fixes: 6147305c ("bcache: set CACHE_SET_IO_DISABLE in bch_cached_dev_error()")
      Reported-by: NYong Li <mr.liyong@qq.com>
      Signed-off-by: NColy Li <colyli@suse.de>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      58169c18
    • W
      crypto: crypto4xx - fix a potential double free in ppc4xx_trng_probe · c3b7d27f
      Wen Yang 提交于
      commit 95566aa75cd6b3b404502c06f66956b5481194b3 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: NWen 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: NJulia Lawall <julia.lawall@lip6.fr>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c3b7d27f
    • C
      crypto: ccp/gcm - use const time tag comparison. · a9fd1795
      Cfir Cohen 提交于
      commit 538a5a072e6ef04377b180ee9b3ce5bae0a85da4 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: NCfir Cohen <cfir@google.com>
      Acked-by: NGary R Hook <ghook@amd.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a9fd1795
    • H
      crypto: ccp - memset structure fields to zero before reuse · 561c4424
      Hook, Gary 提交于
      commit 20e833dc36355ed642d00067641a679c618303fa 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: NGary R Hook <gary.hook@amd.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      561c4424
    • C
      crypto: crypto4xx - block ciphers should only accept complete blocks · 13805a5d
      Christian Lamparter 提交于
      commit 0f7a81374060828280fcfdfbaa162cb559017f9f 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: NChristian Lamparter <chunkeey@gmail.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      13805a5d
    • C
      crypto: crypto4xx - fix blocksize for cfb and ofb · 17e63172
      Christian Lamparter 提交于
      commit 70c4997f34b6c6888b3ac157adec49e01d0df2d5 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: NChristian Lamparter <chunkeey@gmail.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      17e63172
    • C
      crypto: crypto4xx - fix AES CTR blocksize value · 4598094d
      Christian Lamparter 提交于
      commit bfa2ba7d9e6b20aca82b99e6842fe18842ae3a0f 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: NChristian Lamparter <chunkeey@gmail.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4598094d
    • E
      crypto: chacha20poly1305 - fix atomic sleep when using async algorithm · 1c9b0a76
      Eric Biggers 提交于
      commit 7545b6c2087f4ef0287c8c9b7eba6a728c67ff8e 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: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1c9b0a76
    • E
      crypto: arm64/sha2-ce - correct digest for empty data in finup · eb99c084
      Elena Petrova 提交于
      commit 6bd934de1e393466b319d29c4427598fda096c57 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: NElena Petrova <lenaptr@google.com>
      Reviewed-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eb99c084
    • E
      crypto: arm64/sha1-ce - correct digest for empty data in finup · 4230e09e
      Elena Petrova 提交于
      commit 1d4aaf16defa86d2665ae7db0259d6cb07e2091f 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: NElena Petrova <lenaptr@google.com>
      Reviewed-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4230e09e
    • H
      crypto: ccp - Validate the the error value used to index error messages · 52f07c1a
      Hook, Gary 提交于
      commit 52393d617af7b554f03531e6756facf2ea687d2e 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: NCfir Cohen <cfir@google.com>
      Signed-off-by: NGary R Hook <gary.hook@amd.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      52f07c1a
    • E
      crypto: ghash - fix unaligned memory access in ghash_setkey() · bed97f64
      Eric Biggers 提交于
      commit 5c6bc4dfa515738149998bb0db2481a4fdead979 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: NPeter Robinson <pbrobinson@gmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Tested-by: NPeter Robinson <pbrobinson@gmail.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bed97f64
    • F
      scsi: mac_scsi: Fix pseudo DMA implementation, take 2 · ce7ec07a
      Finn Thain 提交于
      commit 78ff751f8e6a9446e9fb26b2bff0b8d3f8974cbd 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: NFinn Thain <fthain@telegraphics.com.au>
      Reported-by: NChris Jones <chris@martin-jones.com>
      Tested-by: NStan Johnson <userm57@yahoo.com>
      Tested-by: NMichael Schmitz <schmitzmic@gmail.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ce7ec07a
    • F
      scsi: mac_scsi: Increase PIO/PDMA transfer length threshold · de769c76
      Finn Thain 提交于
      commit 7398cee4c3e6aea1ba07a6449e5533ecd0b92cdd 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: NFinn Thain <fthain@telegraphics.com.au>
      Tested-by: NStan Johnson <userm57@yahoo.com>
      Tested-by: NMichael Schmitz <schmitzmic@gmail.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      de769c76
    • S
      scsi: megaraid_sas: Fix calculation of target ID · 3e9534fa
      Shivasharan S 提交于
      commit c8f96df5b8e633056b7ebf5d52a9d6fb1b156ce3 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: NShivasharan S <shivasharan.srikanteshwara@broadcom.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3e9534fa
    • M
      scsi: core: Fix race on creating sense cache · 1334a3e2
      Ming Lei 提交于
      commit f9b0530fa02e0c73f31a49ef743e8f44eb8e32cc 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: NMing Lei <ming.lei@redhat.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1334a3e2
    • F
      Revert "scsi: ncr5380: Increase register polling limit" · 58f59f60
      Finn Thain 提交于
      commit 25fcf94a2fa89dd3e73e965ebb0b38a2a4f72aa4 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: NFinn Thain <fthain@telegraphics.com.au>
      Tested-by: NStan Johnson <userm57@yahoo.com>
      Tested-by: NMichael Schmitz <schmitzmic@gmail.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      58f59f60
    • F
      scsi: NCR5380: Always re-enable reselection interrupt · 7cfded7a
      Finn Thain 提交于
      commit 57f31326518e98ee4cabf9a04efe00ed57c54147 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: NFinn Thain <fthain@telegraphics.com.au>
      Tested-by: NStan Johnson <userm57@yahoo.com>
      Tested-by: NMichael Schmitz <schmitzmic@gmail.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7cfded7a
    • F
      scsi: NCR5380: Reduce goto statements in NCR5380_select() · d91baba8
      Finn Thain 提交于
      commit 6a162836997c10bbefb7c7ca772201cc45c0e4a6 upstream.
      
      Replace a 'goto' statement with a simple 'return' where possible.  This
      improves readability. No functional change.
      Tested-by: NMichael Schmitz <schmitzmic@gmail.com>
      Signed-off-by: NFinn Thain <fthain@telegraphics.com.au>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d91baba8
    • J
      xen: let alloc_xenballooned_pages() fail if not enough memory free · e73db096
      Juergen Gross 提交于
      commit a1078e821b605813b63bf6bca414a85f804d5c66 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: NJuergen Gross <jgross@suse.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e73db096
    • D
      floppy: fix out-of-bounds read in copy_buffer · ff54c44f
      Denis Efremov 提交于
      [ Upstream commit da99466ac243f15fbba65bd261bfc75ffa1532b6 ]
      
      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: NDenis Efremov <efremov@ispras.ru>
      Tested-by: NWilly Tarreau <w@1wt.eu>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ff54c44f
    • D
      floppy: fix invalid pointer dereference in drive_name · a9444d9d
      Denis Efremov 提交于
      [ Upstream commit 9b04609b784027968348796a18f601aed9db3789 ]
      
      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: NDenis Efremov <efremov@ispras.ru>
      Tested-by: NWilly Tarreau <w@1wt.eu>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a9444d9d
    • D
      floppy: fix out-of-bounds read in next_valid_format · 5b565f32
      Denis Efremov 提交于
      [ Upstream commit 5635f897ed83fd539df78e98ba69ee91592f9bb8 ]
      
      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: NDenis Efremov <efremov@ispras.ru>
      Tested-by: NWilly Tarreau <w@1wt.eu>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      5b565f32
    • D
      floppy: fix div-by-zero in setup_format_params · 6e34fd07
      Denis Efremov 提交于
      [ Upstream commit f3554aeb991214cbfafd17d55e2bfddb50282e32 ]
      
      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: NDenis Efremov <efremov@ispras.ru>
      Tested-by: NWilly Tarreau <w@1wt.eu>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      6e34fd07
    • C
      iavf: fix dereference of null rx_buffer pointer · 7c16c5ea
      Colin Ian King 提交于
      [ Upstream commit 9fe06a51287b2d41baef7ece94df34b5abf19b90 ]
      
      A recent commit efa14c3985828d ("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: NColin Ian King <colin.king@canonical.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      7c16c5ea
    • J
      net: mvmdio: defer probe of orion-mdio if a clock is not ready · e9896b29
      Josua Mayer 提交于
      [ Upstream commit 433a06d7d74e677c40b1148c70c48677ff62fb6b ]
      
      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: NJosua Mayer <josua@solid-run.com>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e9896b29
    • T
      gtp: fix use-after-free in gtp_newlink() · 5f6c5f5a
      Taehee Yoo 提交于
      [ Upstream commit a2bed90704c68d3763bf24decb1b781a45395de8 ]
      
      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: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      5f6c5f5a
    • T
      gtp: fix use-after-free in gtp_encap_destroy() · 14122221
      Taehee Yoo 提交于
      [ Upstream commit 1788b8569f5de27da09087fa3f6580d2aa04cc75 ]
      
      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: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      14122221
    • T
      gtp: fix Illegal context switch in RCU read-side critical section. · 0a5eca2c
      Taehee Yoo 提交于
      [ Upstream commit 3f167e1921865b379a9becf03828e7202c7b4917 ]
      
      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: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      0a5eca2c
    • T
      gtp: fix suspicious RCU usage · e117a041
      Taehee Yoo 提交于
      [ Upstream commit e198987e7dd7d3645a53875151cd6f8fc425b706 ]
      
      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: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e117a041
    • C
      Bluetooth: validate BLE connection interval updates · 202de90d
      csonsino 提交于
      [ Upstream commit c49a8682fc5d298d44e8d911f4fa14690ea9485e ]
      
      Problem: The Linux Bluetooth stack yields complete control over the BLE
      connection interval to the remote device.
      
      The Linux Bluetooth stack provides access to the BLE connection interval
      min and max values through /sys/kernel/debug/bluetooth/hci0/
      conn_min_interval and /sys/kernel/debug/bluetooth/hci0/conn_max_interval.
      These values are used for initial BLE connections, but the remote device
      has the ability to request a connection parameter update. In the event
      that the remote side requests to change the connection interval, the Linux
      kernel currently only validates that the desired value is within the
      acceptable range in the Bluetooth specification (6 - 3200, corresponding to
      7.5ms - 4000ms). There is currently no validation that the desired value
      requested by the remote device is within the min/max limits specified in
      the conn_min_interval/conn_max_interval configurations. This essentially
      leads to Linux yielding complete control over the connection interval to
      the remote device.
      
      The proposed patch adds a verification step to the connection parameter
      update mechanism, ensuring that the desired value is within the min/max
      bounds of the current connection. If the desired value is outside of the
      current connection min/max values, then the connection parameter update
      request is rejected and the negative response is returned to the remote
      device. Recall that the initial connection is established using the local
      conn_min_interval/conn_max_interval values, so this allows the Linux
      administrator to retain control over the BLE connection interval.
      
      The one downside that I see is that the current default Linux values for
      conn_min_interval and conn_max_interval typically correspond to 30ms and
      50ms respectively. If this change were accepted, then it is feasible that
      some devices would no longer be able to negotiate to their desired
      connection interval values. This might be remedied by setting the default
      Linux conn_min_interval and conn_max_interval values to the widest
      supported range (6 - 3200 / 7.5ms - 4000ms). This could lead to the same
      behavior as the current implementation, where the remote device could
      request to change the connection interval value to any value that is
      permitted by the Bluetooth specification, and Linux would accept the
      desired value.
      Signed-off-by: NCarey Sonsino <csonsino@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      202de90d
    • T
      gtp: add missing gtp_encap_disable_sock() in gtp_encap_enable() · ca33af18
      Taehee Yoo 提交于
      [ Upstream commit e30155fd23c9c141cbe7d99b786e10a83a328837 ]
      
      If an invalid role is sent from user space, gtp_encap_enable() will fail.
      Then, it should call gtp_encap_disable_sock() but current code doesn't.
      It makes memory leak.
      
      Fixes: 91ed81f9 ("gtp: support SGSN-side tunnels")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ca33af18
    • M
      Bluetooth: Check state in l2cap_disconnect_rsp · 0fdb922d
      Matias Karhumaa 提交于
      [ Upstream commit 28261da8a26f4915aa257d12d506c6ba179d961f ]
      
      Because of both sides doing L2CAP disconnection at the same time, it
      was possible to receive L2CAP Disconnection Response with CID that was
      already freed. That caused problems if CID was already reused and L2CAP
      Connection Request with same CID was sent out. Before this patch kernel
      deleted channel context regardless of the state of the channel.
      
      Example where leftover Disconnection Response (frame #402) causes local
      device to delete L2CAP channel which was not yet connected. This in
      turn confuses remote device's stack because same CID is re-used without
      properly disconnecting.
      
      Btmon capture before patch:
      ** snip **
      > ACL Data RX: Handle 43 flags 0x02 dlen 8                #394 [hci1] 10.748949
            Channel: 65 len 4 [PSM 3 mode 0] {chan 2}
            RFCOMM: Disconnect (DISC) (0x43)
               Address: 0x03 cr 1 dlci 0x00
               Control: 0x53 poll/final 1
               Length: 0
               FCS: 0xfd
      < ACL Data TX: Handle 43 flags 0x00 dlen 8                #395 [hci1] 10.749062
            Channel: 65 len 4 [PSM 3 mode 0] {chan 2}
            RFCOMM: Unnumbered Ack (UA) (0x63)
               Address: 0x03 cr 1 dlci 0x00
               Control: 0x73 poll/final 1
               Length: 0
               FCS: 0xd7
      < ACL Data TX: Handle 43 flags 0x00 dlen 12               #396 [hci1] 10.749073
            L2CAP: Disconnection Request (0x06) ident 17 len 4
              Destination CID: 65
              Source CID: 65
      > HCI Event: Number of Completed Packets (0x13) plen 5    #397 [hci1] 10.752391
              Num handles: 1
              Handle: 43
              Count: 1
      > HCI Event: Number of Completed Packets (0x13) plen 5    #398 [hci1] 10.753394
              Num handles: 1
              Handle: 43
              Count: 1
      > ACL Data RX: Handle 43 flags 0x02 dlen 12               #399 [hci1] 10.756499
            L2CAP: Disconnection Request (0x06) ident 26 len 4
              Destination CID: 65
              Source CID: 65
      < ACL Data TX: Handle 43 flags 0x00 dlen 12               #400 [hci1] 10.756548
            L2CAP: Disconnection Response (0x07) ident 26 len 4
              Destination CID: 65
              Source CID: 65
      < ACL Data TX: Handle 43 flags 0x00 dlen 12               #401 [hci1] 10.757459
            L2CAP: Connection Request (0x02) ident 18 len 4
              PSM: 1 (0x0001)
              Source CID: 65
      > ACL Data RX: Handle 43 flags 0x02 dlen 12               #402 [hci1] 10.759148
            L2CAP: Disconnection Response (0x07) ident 17 len 4
              Destination CID: 65
              Source CID: 65
      = bluetoothd: 00:1E:AB:4C:56:54: error updating services: Input/o..   10.759447
      > HCI Event: Number of Completed Packets (0x13) plen 5    #403 [hci1] 10.759386
              Num handles: 1
              Handle: 43
              Count: 1
      > ACL Data RX: Handle 43 flags 0x02 dlen 12               #404 [hci1] 10.760397
            L2CAP: Connection Request (0x02) ident 27 len 4
              PSM: 3 (0x0003)
              Source CID: 65
      < ACL Data TX: Handle 43 flags 0x00 dlen 16               #405 [hci1] 10.760441
            L2CAP: Connection Response (0x03) ident 27 len 8
              Destination CID: 65
              Source CID: 65
              Result: Connection successful (0x0000)
              Status: No further information available (0x0000)
      < ACL Data TX: Handle 43 flags 0x00 dlen 27               #406 [hci1] 10.760449
            L2CAP: Configure Request (0x04) ident 19 len 19
              Destination CID: 65
              Flags: 0x0000
              Option: Maximum Transmission Unit (0x01) [mandatory]
                MTU: 1013
              Option: Retransmission and Flow Control (0x04) [mandatory]
                Mode: Basic (0x00)
                TX window size: 0
                Max transmit: 0
                Retransmission timeout: 0
                Monitor timeout: 0
                Maximum PDU size: 0
      > HCI Event: Number of Completed Packets (0x13) plen 5    #407 [hci1] 10.761399
              Num handles: 1
              Handle: 43
              Count: 1
      > ACL Data RX: Handle 43 flags 0x02 dlen 16               #408 [hci1] 10.762942
            L2CAP: Connection Response (0x03) ident 18 len 8
              Destination CID: 66
              Source CID: 65
              Result: Connection successful (0x0000)
              Status: No further information available (0x0000)
      *snip*
      
      Similar case after the patch:
      *snip*
      > ACL Data RX: Handle 43 flags 0x02 dlen 8            #22702 [hci0] 1664.411056
            Channel: 65 len 4 [PSM 3 mode 0] {chan 3}
            RFCOMM: Disconnect (DISC) (0x43)
               Address: 0x03 cr 1 dlci 0x00
               Control: 0x53 poll/final 1
               Length: 0
               FCS: 0xfd
      < ACL Data TX: Handle 43 flags 0x00 dlen 8            #22703 [hci0] 1664.411136
            Channel: 65 len 4 [PSM 3 mode 0] {chan 3}
            RFCOMM: Unnumbered Ack (UA) (0x63)
               Address: 0x03 cr 1 dlci 0x00
               Control: 0x73 poll/final 1
               Length: 0
               FCS: 0xd7
      < ACL Data TX: Handle 43 flags 0x00 dlen 12           #22704 [hci0] 1664.411143
            L2CAP: Disconnection Request (0x06) ident 11 len 4
              Destination CID: 65
              Source CID: 65
      > HCI Event: Number of Completed Pac.. (0x13) plen 5  #22705 [hci0] 1664.414009
              Num handles: 1
              Handle: 43
              Count: 1
      > HCI Event: Number of Completed Pac.. (0x13) plen 5  #22706 [hci0] 1664.415007
              Num handles: 1
              Handle: 43
              Count: 1
      > ACL Data RX: Handle 43 flags 0x02 dlen 12           #22707 [hci0] 1664.418674
            L2CAP: Disconnection Request (0x06) ident 17 len 4
              Destination CID: 65
              Source CID: 65
      < ACL Data TX: Handle 43 flags 0x00 dlen 12           #22708 [hci0] 1664.418762
            L2CAP: Disconnection Response (0x07) ident 17 len 4
              Destination CID: 65
              Source CID: 65
      < ACL Data TX: Handle 43 flags 0x00 dlen 12           #22709 [hci0] 1664.421073
            L2CAP: Connection Request (0x02) ident 12 len 4
              PSM: 1 (0x0001)
              Source CID: 65
      > ACL Data RX: Handle 43 flags 0x02 dlen 12           #22710 [hci0] 1664.421371
            L2CAP: Disconnection Response (0x07) ident 11 len 4
              Destination CID: 65
              Source CID: 65
      > HCI Event: Number of Completed Pac.. (0x13) plen 5  #22711 [hci0] 1664.424082
              Num handles: 1
              Handle: 43
              Count: 1
      > HCI Event: Number of Completed Pac.. (0x13) plen 5  #22712 [hci0] 1664.425040
              Num handles: 1
              Handle: 43
              Count: 1
      > ACL Data RX: Handle 43 flags 0x02 dlen 12           #22713 [hci0] 1664.426103
            L2CAP: Connection Request (0x02) ident 18 len 4
              PSM: 3 (0x0003)
              Source CID: 65
      < ACL Data TX: Handle 43 flags 0x00 dlen 16           #22714 [hci0] 1664.426186
            L2CAP: Connection Response (0x03) ident 18 len 8
              Destination CID: 66
              Source CID: 65
              Result: Connection successful (0x0000)
              Status: No further information available (0x0000)
      < ACL Data TX: Handle 43 flags 0x00 dlen 27           #22715 [hci0] 1664.426196
            L2CAP: Configure Request (0x04) ident 13 len 19
              Destination CID: 65
              Flags: 0x0000
              Option: Maximum Transmission Unit (0x01) [mandatory]
                MTU: 1013
              Option: Retransmission and Flow Control (0x04) [mandatory]
                Mode: Basic (0x00)
                TX window size: 0
                Max transmit: 0
                Retransmission timeout: 0
                Monitor timeout: 0
                Maximum PDU size: 0
      > ACL Data RX: Handle 43 flags 0x02 dlen 16           #22716 [hci0] 1664.428804
            L2CAP: Connection Response (0x03) ident 12 len 8
              Destination CID: 66
              Source CID: 65
              Result: Connection successful (0x0000)
              Status: No further information available (0x0000)
      *snip*
      
      Fix is to check that channel is in state BT_DISCONN before deleting the
      channel.
      
      This bug was found while fuzzing Bluez's OBEX implementation using
      Synopsys Defensics.
      Reported-by: NMatti Kamunen <matti.kamunen@synopsys.com>
      Reported-by: NAri Timonen <ari.timonen@synopsys.com>
      Signed-off-by: NMatias Karhumaa <matias.karhumaa@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      0fdb922d
    • S
      perf tests: Fix record+probe_libc_inet_pton.sh for powerpc64 · 3b57b7a3
      Seeteena Thoufeek 提交于
      [ Upstream commit bff5a556c149804de29347a88a884d25e4e4e3a2 ]
      
      'probe libc's inet_pton & backtrace it with ping' testcase sometimes
      fails on powerpc because distro ping binary does not have symbol
      information and thus it prints "[unknown]" function name in the
      backtrace.
      
      Accept "[unknown]" as valid function name for powerpc as well.
      
       # perf test -v "probe libc's inet_pton & backtrace it with ping"
      
      Before:
      
        59: probe libc's inet_pton & backtrace it with ping       :
        --- start ---
        test child forked, pid 79695
        ping 79718 [077] 96483.787025: probe_libc:inet_pton: (7fff83a754c8)
        7fff83a754c8 __GI___inet_pton+0x8 (/usr/lib64/power9/libc-2.28.so)
        7fff83a2b7a0 gaih_inet.constprop.7+0x1020
        (/usr/lib64/power9/libc-2.28.so)
        7fff83a2c170 getaddrinfo+0x160 (/usr/lib64/power9/libc-2.28.so)
        1171830f4 [unknown] (/usr/bin/ping)
        FAIL: expected backtrace entry
        ".*\+0x[[:xdigit:]]+[[:space:]]\(.*/bin/ping.*\)$"
        got "1171830f4 [unknown] (/usr/bin/ping)"
        test child finished with -1
        ---- end ----
        probe libc's inet_pton & backtrace it with ping: FAILED!
      
      After:
      
        59: probe libc's inet_pton & backtrace it with ping       :
        --- start ---
        test child forked, pid 79085
        ping 79108 [045] 96400.214177: probe_libc:inet_pton: (7fffbb9654c8)
        7fffbb9654c8 __GI___inet_pton+0x8 (/usr/lib64/power9/libc-2.28.so)
        7fffbb91b7a0 gaih_inet.constprop.7+0x1020
        (/usr/lib64/power9/libc-2.28.so)
        7fffbb91c170 getaddrinfo+0x160 (/usr/lib64/power9/libc-2.28.so)
        132e830f4 [unknown] (/usr/bin/ping)
        test child finished with 0
        ---- end ----
        probe libc's inet_pton & backtrace it with ping: Ok
      Signed-off-by: NSeeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
      Reviewed-by: NKim Phillips <kim.phillips@amd.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Hendrik Brueckner <brueckner@linux.ibm.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Michael Petlan <mpetlan@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Sandipan Das <sandipan@linux.ibm.com>
      Fixes: 1632936480a5 ("perf tests: Fix record+probe_libc_inet_pton.sh without ping's debuginfo")
      Link: http://lkml.kernel.org/r/1561630614-3216-1-git-send-email-s1seetee@linux.vnet.ibm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      3b57b7a3
    • J
      Bluetooth: 6lowpan: search for destination address in all peers · c814f618
      Josua Mayer 提交于
      [ Upstream commit b188b03270b7f8568fc714101ce82fbf5e811c5a ]
      
      Handle overlooked case where the target address is assigned to a peer
      and neither route nor gateway exist.
      
      For one peer, no checks are performed to see if it is meant to receive
      packets for a given address.
      
      As soon as there is a second peer however, checks are performed
      to deal with routes and gateways for handling complex setups with
      multiple hops to a target address.
      This logic assumed that no route and no gateway imply that the
      destination address can not be reached, which is false in case of a
      direct peer.
      Acked-by: NJukka Rissanen <jukka.rissanen@linux.intel.com>
      Tested-by: NMichael Scott <mike@foundries.io>
      Signed-off-by: NJosua Mayer <josua.mayer@jm0.eu>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      c814f618
    • J
      Bluetooth: Add new 13d3:3501 QCA_ROME device · c82c4910
      João Paulo Rechi Vita 提交于
      [ Upstream commit 881cec4f6b4da78e54b73c046a60f39315964c7d ]
      
      Without the QCA ROME setup routine this adapter fails to establish a SCO
      connection.
      
      T:  Bus=01 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#=  2 Spd=12  MxCh= 0
      D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=13d3 ProdID=3501 Rev=00.01
      C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
      I:  If#=0x0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      I:  If#=0x1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      Signed-off-by: NJoão Paulo Rechi Vita <jprvita@endlessm.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      c82c4910
    • J
      Bluetooth: Add new 13d3:3491 QCA_ROME device · 1cbce19b
      João Paulo Rechi Vita 提交于
      [ Upstream commit 44d34af2e4cfd0c5357182f8b43f3e0a1fe30a2e ]
      
      Without the QCA ROME setup routine this adapter fails to establish a SCO
      connection.
      
      T:  Bus=01 Lev=01 Prnt=01 Port=08 Cnt=01 Dev#=  2 Spd=12  MxCh= 0
      D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=13d3 ProdID=3491 Rev=00.01
      C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
      I:  If#=0x0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      I:  If#=0x1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      Signed-off-by: NJoão Paulo Rechi Vita <jprvita@endlessm.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      1cbce19b
    • T
      Bluetooth: hci_bcsp: Fix memory leak in rx_skb · 578658df
      Tomas Bortoli 提交于
      [ Upstream commit 4ce9146e0370fcd573f0372d9b4e5a211112567c ]
      
      Syzkaller found that it is possible to provoke a memory leak by
      never freeing rx_skb in struct bcsp_struct.
      
      Fix by freeing in bcsp_close()
      Signed-off-by: NTomas Bortoli <tomasbortoli@gmail.com>
      Reported-by: syzbot+98162c885993b72f19c4@syzkaller.appspotmail.com
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      578658df
    • J
      tools: bpftool: Fix json dump crash on powerpc · 9d47bd21
      Jiri Olsa 提交于
      [ Upstream commit aa52bcbe0e72fac36b1862db08b9c09c4caefae3 ]
      
      Michael reported crash with by bpf program in json mode on powerpc:
      
        # bpftool prog -p dump jited id 14
        [{
              "name": "0xd00000000a9aa760",
              "insns": [{
                      "pc": "0x0",
                      "operation": "nop",
                      "operands": [null
                      ]
                  },{
                      "pc": "0x4",
                      "operation": "nop",
                      "operands": [null
                      ]
                  },{
                      "pc": "0x8",
                      "operation": "mflr",
        Segmentation fault (core dumped)
      
      The code is assuming char pointers in format, which is not always
      true at least for powerpc. Fixing this by dumping the whole string
      into buffer based on its format.
      
      Please note that libopcodes code does not check return values from
      fprintf callback, but as per Jakub suggestion returning -1 on allocation
      failure so we do the best effort to propagate the error.
      
      Fixes: 107f0412 ("tools: bpftool: add JSON output for `bpftool prog dump jited *` command")
      Reported-by: NMichael Petlan <mpetlan@redhat.com>
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Reviewed-by: NQuentin Monnet <quentin.monnet@netronome.com>
      Reviewed-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      9d47bd21
    • G
      gpiolib: Fix references to gpiod_[gs]et_*value_cansleep() variants · 2ad04d31
      Geert Uytterhoeven 提交于
      [ Upstream commit 3285170f28a850638794cdfe712eb6d93e51e706 ]
      
      Commit 372e722e ("gpiolib: use descriptors internally") renamed
      the functions to use a "gpiod" prefix, and commit 79a9becd
      ("gpiolib: export descriptor-based GPIO interface") introduced the "raw"
      variants, but both changes forgot to update the comments.
      
      Readd a similar reference to gpiod_set_value(), which was accidentally
      removed by commit 1e77fc82 ("gpio: Add missing open drain/source
      handling to gpiod_set_value_cansleep()").
      Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Link: https://lore.kernel.org/r/20190701142738.25219-1-geert+renesas@glider.beSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      2ad04d31