From: Greg Kroah-Hartman Date: Wed, 15 Sep 2021 12:56:15 +0000 (+0200) Subject: 4.14-stable patches X-Git-Tag: v5.14.5~40 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=cc7748000beed71993bfb17614052af6f874a6cf;p=thirdparty%2Fkernel%2Fstable-queue.git 4.14-stable patches added patches: block-bfq-fix-bfq_set_next_ioprio_data.patch crypto-public_key-fix-overflow-during-implicit-conversion.patch dm-crypt-avoid-percpu_counter-spinlock-contention-in-crypt_page_alloc.patch media-rc-loopback-return-number-of-emitters-rather-than-error.patch media-uvc-don-t-do-dma-on-stack.patch power-supply-max17042-handle-fails-of-reading-status-register.patch soc-aspeed-lpc-ctrl-fix-boundary-check-for-mmap.patch vmci-fix-null-pointer-dereference-when-unmapping-queue-pair.patch --- diff --git a/queue-4.14/block-bfq-fix-bfq_set_next_ioprio_data.patch b/queue-4.14/block-bfq-fix-bfq_set_next_ioprio_data.patch new file mode 100644 index 00000000000..b340bb084d5 --- /dev/null +++ b/queue-4.14/block-bfq-fix-bfq_set_next_ioprio_data.patch @@ -0,0 +1,38 @@ +From a680dd72ec336b81511e3bff48efac6dbfa563e7 Mon Sep 17 00:00:00 2001 +From: Damien Le Moal +Date: Wed, 11 Aug 2021 12:36:57 +0900 +Subject: block: bfq: fix bfq_set_next_ioprio_data() + +From: Damien Le Moal + +commit a680dd72ec336b81511e3bff48efac6dbfa563e7 upstream. + +For a request that has a priority level equal to or larger than +IOPRIO_BE_NR, bfq_set_next_ioprio_data() prints a critical warning but +defaults to setting the request new_ioprio field to IOPRIO_BE_NR. This +is not consistent with the warning and the allowed values for priority +levels. Fix this by setting the request new_ioprio field to +IOPRIO_BE_NR - 1, the lowest priority level allowed. + +Cc: +Fixes: aee69d78dec0 ("block, bfq: introduce the BFQ-v0 I/O scheduler as an extra scheduler") +Signed-off-by: Damien Le Moal +Reviewed-by: Hannes Reinecke +Link: https://lore.kernel.org/r/20210811033702.368488-2-damien.lemoal@wdc.com +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + block/bfq-iosched.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/block/bfq-iosched.c ++++ b/block/bfq-iosched.c +@@ -3825,7 +3825,7 @@ bfq_set_next_ioprio_data(struct bfq_queu + if (bfqq->new_ioprio >= IOPRIO_BE_NR) { + pr_crit("bfq_set_next_ioprio_data: new_ioprio %d\n", + bfqq->new_ioprio); +- bfqq->new_ioprio = IOPRIO_BE_NR; ++ bfqq->new_ioprio = IOPRIO_BE_NR - 1; + } + + bfqq->entity.new_weight = bfq_ioprio_to_weight(bfqq->new_ioprio); diff --git a/queue-4.14/crypto-public_key-fix-overflow-during-implicit-conversion.patch b/queue-4.14/crypto-public_key-fix-overflow-during-implicit-conversion.patch new file mode 100644 index 00000000000..37ed417036a --- /dev/null +++ b/queue-4.14/crypto-public_key-fix-overflow-during-implicit-conversion.patch @@ -0,0 +1,70 @@ +From f985911b7bc75d5c98ed24d8aaa8b94c590f7c6a Mon Sep 17 00:00:00 2001 +From: zhenwei pi +Date: Thu, 19 Aug 2021 20:37:10 +0800 +Subject: crypto: public_key: fix overflow during implicit conversion + +From: zhenwei pi + +commit f985911b7bc75d5c98ed24d8aaa8b94c590f7c6a upstream. + +Hit kernel warning like this, it can be reproduced by verifying 256 +bytes datafile by keyctl command, run script: +RAWDATA=rawdata +SIGDATA=sigdata + +modprobe pkcs8_key_parser + +rm -rf *.der *.pem *.pfx +rm -rf $RAWDATA +dd if=/dev/random of=$RAWDATA bs=256 count=1 + +openssl req -nodes -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem \ + -subj "/C=CN/ST=GD/L=SZ/O=vihoo/OU=dev/CN=xx.com/emailAddress=yy@xx.com" + +KEY_ID=`openssl pkcs8 -in key.pem -topk8 -nocrypt -outform DER | keyctl \ + padd asymmetric 123 @s` + +keyctl pkey_sign $KEY_ID 0 $RAWDATA enc=pkcs1 hash=sha1 > $SIGDATA +keyctl pkey_verify $KEY_ID 0 $RAWDATA $SIGDATA enc=pkcs1 hash=sha1 + +Then the kernel reports: + WARNING: CPU: 5 PID: 344556 at crypto/rsa-pkcs1pad.c:540 + pkcs1pad_verify+0x160/0x190 + ... + Call Trace: + public_key_verify_signature+0x282/0x380 + ? software_key_query+0x12d/0x180 + ? keyctl_pkey_params_get+0xd6/0x130 + asymmetric_key_verify_signature+0x66/0x80 + keyctl_pkey_verify+0xa5/0x100 + do_syscall_64+0x35/0xb0 + entry_SYSCALL_64_after_hwframe+0x44/0xae + +The reason of this issue, in function 'asymmetric_key_verify_signature': +'.digest_size(u8) = params->in_len(u32)' leads overflow of an u8 value, +so use u32 instead of u8 for digest_size field. And reorder struct +public_key_signature, it saves 8 bytes on a 64-bit machine. + +Cc: stable@vger.kernel.org +Signed-off-by: zhenwei pi +Reviewed-by: Jarkko Sakkinen +Signed-off-by: Jarkko Sakkinen +Signed-off-by: Greg Kroah-Hartman +--- + include/crypto/public_key.h | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/include/crypto/public_key.h ++++ b/include/crypto/public_key.h +@@ -35,9 +35,9 @@ extern void public_key_free(struct publi + struct public_key_signature { + struct asymmetric_key_id *auth_ids[2]; + u8 *s; /* Signature */ +- u32 s_size; /* Number of bytes in signature */ + u8 *digest; +- u8 digest_size; /* Number of bytes in digest */ ++ u32 s_size; /* Number of bytes in signature */ ++ u32 digest_size; /* Number of bytes in digest */ + const char *pkey_algo; + const char *hash_algo; + }; diff --git a/queue-4.14/dm-crypt-avoid-percpu_counter-spinlock-contention-in-crypt_page_alloc.patch b/queue-4.14/dm-crypt-avoid-percpu_counter-spinlock-contention-in-crypt_page_alloc.patch new file mode 100644 index 00000000000..5e1f058fce8 --- /dev/null +++ b/queue-4.14/dm-crypt-avoid-percpu_counter-spinlock-contention-in-crypt_page_alloc.patch @@ -0,0 +1,128 @@ +From 528b16bfc3ae5f11638e71b3b63a81f9999df727 Mon Sep 17 00:00:00 2001 +From: Arne Welzel +Date: Sat, 14 Aug 2021 00:40:38 +0200 +Subject: dm crypt: Avoid percpu_counter spinlock contention in crypt_page_alloc() + +From: Arne Welzel + +commit 528b16bfc3ae5f11638e71b3b63a81f9999df727 upstream. + +On systems with many cores using dm-crypt, heavy spinlock contention in +percpu_counter_compare() can be observed when the page allocation limit +for a given device is reached or close to be reached. This is due +to percpu_counter_compare() taking a spinlock to compute an exact +result on potentially many CPUs at the same time. + +Switch to non-exact comparison of allocated and allowed pages by using +the value returned by percpu_counter_read_positive() to avoid taking +the percpu_counter spinlock. + +This may over/under estimate the actual number of allocated pages by at +most (batch-1) * num_online_cpus(). + +Currently, batch is bounded by 32. The system on which this issue was +first observed has 256 CPUs and 512GB of RAM. With a 4k page size, this +change may over/under estimate by 31MB. With ~10G (2%) allowed dm-crypt +allocations, this seems an acceptable error. Certainly preferred over +running into the spinlock contention. + +This behavior was reproduced on an EC2 c5.24xlarge instance with 96 CPUs +and 192GB RAM as follows, but can be provoked on systems with less CPUs +as well. + + * Disable swap + * Tune vm settings to promote regular writeback + $ echo 50 > /proc/sys/vm/dirty_expire_centisecs + $ echo 25 > /proc/sys/vm/dirty_writeback_centisecs + $ echo $((128 * 1024 * 1024)) > /proc/sys/vm/dirty_background_bytes + + * Create 8 dmcrypt devices based on files on a tmpfs + * Create and mount an ext4 filesystem on each crypt devices + * Run stress-ng --hdd 8 within one of above filesystems + +Total %system usage collected from sysstat goes to ~35%. Write throughput +on the underlying loop device is ~2GB/s. perf profiling an individual +kworker kcryptd thread shows the following profile, indicating spinlock +contention in percpu_counter_compare(): + + 99.98% 0.00% kworker/u193:46 [kernel.kallsyms] [k] ret_from_fork + | + --ret_from_fork + kthread + worker_thread + | + --99.92%--process_one_work + | + |--80.52%--kcryptd_crypt + | | + | |--62.58%--mempool_alloc + | | | + | | --62.24%--crypt_page_alloc + | | | + | | --61.51%--__percpu_counter_compare + | | | + | | --61.34%--__percpu_counter_sum + | | | + | | |--58.68%--_raw_spin_lock_irqsave + | | | | + | | | --58.30%--native_queued_spin_lock_slowpath + | | | + | | --0.69%--cpumask_next + | | | + | | --0.51%--_find_next_bit + | | + | |--10.61%--crypt_convert + | | | + | | |--6.05%--xts_crypt + ... + +After applying this patch and running the same test, %system usage is +lowered to ~7% and write throughput on the loop device increases +to ~2.7GB/s. perf report shows mempool_alloc() as ~8% rather than ~62% +in the profile and not hitting the percpu_counter() spinlock anymore. + + |--8.15%--mempool_alloc + | | + | |--3.93%--crypt_page_alloc + | | | + | | --3.75%--__alloc_pages + | | | + | | --3.62%--get_page_from_freelist + | | | + | | --3.22%--rmqueue_bulk + | | | + | | --2.59%--_raw_spin_lock + | | | + | | --2.57%--native_queued_spin_lock_slowpath + | | + | --3.05%--_raw_spin_lock_irqsave + | | + | --2.49%--native_queued_spin_lock_slowpath + +Suggested-by: DJ Gregor +Reviewed-by: Mikulas Patocka +Signed-off-by: Arne Welzel +Fixes: 5059353df86e ("dm crypt: limit the number of allocated pages") +Cc: stable@vger.kernel.org +Signed-off-by: Mike Snitzer +Signed-off-by: Greg Kroah-Hartman +--- + drivers/md/dm-crypt.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +--- a/drivers/md/dm-crypt.c ++++ b/drivers/md/dm-crypt.c +@@ -2188,7 +2188,12 @@ static void *crypt_page_alloc(gfp_t gfp_ + struct crypt_config *cc = pool_data; + struct page *page; + +- if (unlikely(percpu_counter_compare(&cc->n_allocated_pages, dm_crypt_pages_per_client) >= 0) && ++ /* ++ * Note, percpu_counter_read_positive() may over (and under) estimate ++ * the current usage by at most (batch - 1) * num_online_cpus() pages, ++ * but avoids potential spinlock contention of an exact result. ++ */ ++ if (unlikely(percpu_counter_read_positive(&cc->n_allocated_pages) >= dm_crypt_pages_per_client) && + likely(gfp_mask & __GFP_NORETRY)) + return NULL; + diff --git a/queue-4.14/media-rc-loopback-return-number-of-emitters-rather-than-error.patch b/queue-4.14/media-rc-loopback-return-number-of-emitters-rather-than-error.patch new file mode 100644 index 00000000000..a0a30e2ecb4 --- /dev/null +++ b/queue-4.14/media-rc-loopback-return-number-of-emitters-rather-than-error.patch @@ -0,0 +1,31 @@ +From 6b7f554be8c92319d7e6df92fd247ebb9beb4a45 Mon Sep 17 00:00:00 2001 +From: Sean Young +Date: Sat, 3 Jul 2021 15:37:17 +0200 +Subject: media: rc-loopback: return number of emitters rather than error + +From: Sean Young + +commit 6b7f554be8c92319d7e6df92fd247ebb9beb4a45 upstream. + +The LIRC_SET_TRANSMITTER_MASK ioctl should return the number of emitters +if an invalid list was set. + +Cc: stable@vger.kernel.org +Signed-off-by: Sean Young +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman +--- + drivers/media/rc/rc-loopback.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/media/rc/rc-loopback.c ++++ b/drivers/media/rc/rc-loopback.c +@@ -52,7 +52,7 @@ static int loop_set_tx_mask(struct rc_de + + if ((mask & (RXMASK_REGULAR | RXMASK_LEARNING)) != mask) { + dprintk("invalid tx mask: %u\n", mask); +- return -EINVAL; ++ return 2; + } + + dprintk("setting tx mask: %u\n", mask); diff --git a/queue-4.14/media-uvc-don-t-do-dma-on-stack.patch b/queue-4.14/media-uvc-don-t-do-dma-on-stack.patch new file mode 100644 index 00000000000..44ee618faa3 --- /dev/null +++ b/queue-4.14/media-uvc-don-t-do-dma-on-stack.patch @@ -0,0 +1,96 @@ +From 1a10d7fdb6d0e235e9d230916244cc2769d3f170 Mon Sep 17 00:00:00 2001 +From: Mauro Carvalho Chehab +Date: Thu, 17 Jun 2021 14:33:29 +0200 +Subject: media: uvc: don't do DMA on stack + +From: Mauro Carvalho Chehab + +commit 1a10d7fdb6d0e235e9d230916244cc2769d3f170 upstream. + +As warned by smatch: + drivers/media/usb/uvc/uvc_v4l2.c:911 uvc_ioctl_g_input() error: doing dma on the stack (&i) + drivers/media/usb/uvc/uvc_v4l2.c:943 uvc_ioctl_s_input() error: doing dma on the stack (&i) + +those two functions call uvc_query_ctrl passing a pointer to +a data at the DMA stack. those are used to send URBs via +usb_control_msg(). Using DMA stack is not supported and should +not work anymore on modern Linux versions. + +So, use a kmalloc'ed buffer. + +Cc: stable@vger.kernel.org # Kernel 4.9 and upper +Reviewed-by: Laurent Pinchart +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman +--- + drivers/media/usb/uvc/uvc_v4l2.c | 34 +++++++++++++++++++++++----------- + 1 file changed, 23 insertions(+), 11 deletions(-) + +--- a/drivers/media/usb/uvc/uvc_v4l2.c ++++ b/drivers/media/usb/uvc/uvc_v4l2.c +@@ -876,8 +876,8 @@ static int uvc_ioctl_g_input(struct file + { + struct uvc_fh *handle = fh; + struct uvc_video_chain *chain = handle->chain; ++ u8 *buf; + int ret; +- u8 i; + + if (chain->selector == NULL || + (chain->dev->quirks & UVC_QUIRK_IGNORE_SELECTOR_UNIT)) { +@@ -885,22 +885,27 @@ static int uvc_ioctl_g_input(struct file + return 0; + } + ++ buf = kmalloc(1, GFP_KERNEL); ++ if (!buf) ++ return -ENOMEM; ++ + ret = uvc_query_ctrl(chain->dev, UVC_GET_CUR, chain->selector->id, + chain->dev->intfnum, UVC_SU_INPUT_SELECT_CONTROL, +- &i, 1); +- if (ret < 0) +- return ret; ++ buf, 1); ++ if (!ret) ++ *input = *buf - 1; + +- *input = i - 1; +- return 0; ++ kfree(buf); ++ ++ return ret; + } + + static int uvc_ioctl_s_input(struct file *file, void *fh, unsigned int input) + { + struct uvc_fh *handle = fh; + struct uvc_video_chain *chain = handle->chain; ++ u8 *buf; + int ret; +- u32 i; + + ret = uvc_acquire_privileges(handle); + if (ret < 0) +@@ -916,10 +921,17 @@ static int uvc_ioctl_s_input(struct file + if (input >= chain->selector->bNrInPins) + return -EINVAL; + +- i = input + 1; +- return uvc_query_ctrl(chain->dev, UVC_SET_CUR, chain->selector->id, +- chain->dev->intfnum, UVC_SU_INPUT_SELECT_CONTROL, +- &i, 1); ++ buf = kmalloc(1, GFP_KERNEL); ++ if (!buf) ++ return -ENOMEM; ++ ++ *buf = input + 1; ++ ret = uvc_query_ctrl(chain->dev, UVC_SET_CUR, chain->selector->id, ++ chain->dev->intfnum, UVC_SU_INPUT_SELECT_CONTROL, ++ buf, 1); ++ kfree(buf); ++ ++ return ret; + } + + static int uvc_ioctl_queryctrl(struct file *file, void *fh, diff --git a/queue-4.14/power-supply-max17042-handle-fails-of-reading-status-register.patch b/queue-4.14/power-supply-max17042-handle-fails-of-reading-status-register.patch new file mode 100644 index 00000000000..da15f7c53e9 --- /dev/null +++ b/queue-4.14/power-supply-max17042-handle-fails-of-reading-status-register.patch @@ -0,0 +1,43 @@ +From 54784ffa5b267f57161eb8fbb811499f22a0a0bf Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Mon, 16 Aug 2021 10:27:14 +0200 +Subject: power: supply: max17042: handle fails of reading status register + +From: Krzysztof Kozlowski + +commit 54784ffa5b267f57161eb8fbb811499f22a0a0bf upstream. + +Reading status register can fail in the interrupt handler. In such +case, the regmap_read() will not store anything useful under passed +'val' variable and random stack value will be used to determine type of +interrupt. + +Handle the regmap_read() failure to avoid handling interrupt type and +triggering changed power supply event based on random stack value. + +Fixes: 39e7213edc4f ("max17042_battery: Support regmap to access device's registers") +Cc: +Signed-off-by: Krzysztof Kozlowski +Reviewed-by: Hans de Goede +Signed-off-by: Sebastian Reichel +Signed-off-by: Greg Kroah-Hartman +--- + drivers/power/supply/max17042_battery.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/drivers/power/supply/max17042_battery.c ++++ b/drivers/power/supply/max17042_battery.c +@@ -833,8 +833,12 @@ static irqreturn_t max17042_thread_handl + { + struct max17042_chip *chip = dev; + u32 val; ++ int ret; ++ ++ ret = regmap_read(chip->regmap, MAX17042_STATUS, &val); ++ if (ret) ++ return IRQ_HANDLED; + +- regmap_read(chip->regmap, MAX17042_STATUS, &val); + if ((val & STATUS_INTR_SOCMIN_BIT) || + (val & STATUS_INTR_SOCMAX_BIT)) { + dev_info(&chip->client->dev, "SOC threshold INTR\n"); diff --git a/queue-4.14/series b/queue-4.14/series index 361c14ed717..ef74deefee0 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -105,3 +105,11 @@ powerpc-perf-hv-gpci-fix-counter-value-parsing.patch xen-fix-setting-of-max_pfn-in-shared_info.patch include-linux-list.h-add-a-macro-to-test-if-entry-is-pointing-to-the-head.patch 9p-xen-fix-end-of-loop-tests-for-list_for_each_entry.patch +soc-aspeed-lpc-ctrl-fix-boundary-check-for-mmap.patch +crypto-public_key-fix-overflow-during-implicit-conversion.patch +block-bfq-fix-bfq_set_next_ioprio_data.patch +power-supply-max17042-handle-fails-of-reading-status-register.patch +dm-crypt-avoid-percpu_counter-spinlock-contention-in-crypt_page_alloc.patch +vmci-fix-null-pointer-dereference-when-unmapping-queue-pair.patch +media-uvc-don-t-do-dma-on-stack.patch +media-rc-loopback-return-number-of-emitters-rather-than-error.patch diff --git a/queue-4.14/soc-aspeed-lpc-ctrl-fix-boundary-check-for-mmap.patch b/queue-4.14/soc-aspeed-lpc-ctrl-fix-boundary-check-for-mmap.patch new file mode 100644 index 00000000000..f7bd12cc6a8 --- /dev/null +++ b/queue-4.14/soc-aspeed-lpc-ctrl-fix-boundary-check-for-mmap.patch @@ -0,0 +1,38 @@ +From b49a0e69a7b1a68c8d3f64097d06dabb770fec96 Mon Sep 17 00:00:00 2001 +From: Iwona Winiarska +Date: Wed, 4 Aug 2021 01:48:18 +0200 +Subject: soc: aspeed: lpc-ctrl: Fix boundary check for mmap + +From: Iwona Winiarska + +commit b49a0e69a7b1a68c8d3f64097d06dabb770fec96 upstream. + +The check mixes pages (vm_pgoff) with bytes (vm_start, vm_end) on one +side of the comparison, and uses resource address (rather than just the +resource size) on the other side of the comparison. +This can allow malicious userspace to easily bypass the boundary check and +map pages that are located outside memory-region reserved by the driver. + +Fixes: 6c4e97678501 ("drivers/misc: Add Aspeed LPC control driver") +Cc: stable@vger.kernel.org +Signed-off-by: Iwona Winiarska +Reviewed-by: Andrew Jeffery +Tested-by: Andrew Jeffery +Reviewed-by: Joel Stanley +Signed-off-by: Joel Stanley +Signed-off-by: Greg Kroah-Hartman +--- + drivers/misc/aspeed-lpc-ctrl.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/misc/aspeed-lpc-ctrl.c ++++ b/drivers/misc/aspeed-lpc-ctrl.c +@@ -44,7 +44,7 @@ static int aspeed_lpc_ctrl_mmap(struct f + unsigned long vsize = vma->vm_end - vma->vm_start; + pgprot_t prot = vma->vm_page_prot; + +- if (vma->vm_pgoff + vsize > lpc_ctrl->mem_base + lpc_ctrl->mem_size) ++ if (vma->vm_pgoff + vma_pages(vma) > lpc_ctrl->mem_size >> PAGE_SHIFT) + return -EINVAL; + + /* ast2400/2500 AHB accesses are not cache coherent */ diff --git a/queue-4.14/vmci-fix-null-pointer-dereference-when-unmapping-queue-pair.patch b/queue-4.14/vmci-fix-null-pointer-dereference-when-unmapping-queue-pair.patch new file mode 100644 index 00000000000..27df6f4fa13 --- /dev/null +++ b/queue-4.14/vmci-fix-null-pointer-dereference-when-unmapping-queue-pair.patch @@ -0,0 +1,79 @@ +From a30dc6cf0dc51419021550152e435736aaef8799 Mon Sep 17 00:00:00 2001 +From: Wang Hai +Date: Wed, 18 Aug 2021 20:48:45 +0800 +Subject: VMCI: fix NULL pointer dereference when unmapping queue pair + +From: Wang Hai + +commit a30dc6cf0dc51419021550152e435736aaef8799 upstream. + +I got a NULL pointer dereference report when doing fuzz test: + +Call Trace: + qp_release_pages+0xae/0x130 + qp_host_unregister_user_memory.isra.25+0x2d/0x80 + vmci_qp_broker_unmap+0x191/0x320 + ? vmci_host_do_alloc_queuepair.isra.9+0x1c0/0x1c0 + vmci_host_unlocked_ioctl+0x59f/0xd50 + ? do_vfs_ioctl+0x14b/0xa10 + ? tomoyo_file_ioctl+0x28/0x30 + ? vmci_host_do_alloc_queuepair.isra.9+0x1c0/0x1c0 + __x64_sys_ioctl+0xea/0x120 + do_syscall_64+0x34/0xb0 + entry_SYSCALL_64_after_hwframe+0x44/0xae + +When a queue pair is created by the following call, it will not +register the user memory if the page_store is NULL, and the +entry->state will be set to VMCIQPB_CREATED_NO_MEM. + +vmci_host_unlocked_ioctl + vmci_host_do_alloc_queuepair + vmci_qp_broker_alloc + qp_broker_alloc + qp_broker_create // set entry->state = VMCIQPB_CREATED_NO_MEM; + +When unmapping this queue pair, qp_host_unregister_user_memory() will +be called to unregister the non-existent user memory, which will +result in a null pointer reference. It will also change +VMCIQPB_CREATED_NO_MEM to VMCIQPB_CREATED_MEM, which should not be +present in this operation. + +Only when the qp broker has mem, it can unregister the user +memory when unmapping the qp broker. + +Only when the qp broker has no mem, it can register the user +memory when mapping the qp broker. + +Fixes: 06164d2b72aa ("VMCI: queue pairs implementation.") +Cc: stable +Reported-by: Hulk Robot +Reviewed-by: Jorgen Hansen +Signed-off-by: Wang Hai +Link: https://lore.kernel.org/r/20210818124845.488312-1-wanghai38@huawei.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/misc/vmw_vmci/vmci_queue_pair.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/drivers/misc/vmw_vmci/vmci_queue_pair.c ++++ b/drivers/misc/vmw_vmci/vmci_queue_pair.c +@@ -2338,7 +2338,8 @@ int vmci_qp_broker_map(struct vmci_handl + is_local = entry->qp.flags & VMCI_QPFLAG_LOCAL; + result = VMCI_SUCCESS; + +- if (context_id != VMCI_HOST_CONTEXT_ID) { ++ if (context_id != VMCI_HOST_CONTEXT_ID && ++ !QPBROKERSTATE_HAS_MEM(entry)) { + struct vmci_qp_page_store page_store; + + page_store.pages = guest_mem; +@@ -2448,7 +2449,8 @@ int vmci_qp_broker_unmap(struct vmci_han + + is_local = entry->qp.flags & VMCI_QPFLAG_LOCAL; + +- if (context_id != VMCI_HOST_CONTEXT_ID) { ++ if (context_id != VMCI_HOST_CONTEXT_ID && ++ QPBROKERSTATE_HAS_MEM(entry)) { + qp_acquire_queue_mutex(entry->produce_q); + result = qp_save_headers(entry); + if (result < VMCI_SUCCESS)