From: Greg Kroah-Hartman Date: Tue, 10 Mar 2020 12:17:46 +0000 (+0100) Subject: 4.4-stable patches X-Git-Tag: v4.4.216~11 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=2994b8c000e7bb8156fb8dc50a86d32f0528c30c;p=thirdparty%2Fkernel%2Fstable-queue.git 4.4-stable patches added patches: crypto-algif_skcipher-use-zero_or_null_ptr-in-skcipher_recvmsg_async.patch dm-cache-fix-a-crash-due-to-incorrect-work-item-cancelling.patch --- diff --git a/queue-4.4/crypto-algif_skcipher-use-zero_or_null_ptr-in-skcipher_recvmsg_async.patch b/queue-4.4/crypto-algif_skcipher-use-zero_or_null_ptr-in-skcipher_recvmsg_async.patch new file mode 100644 index 00000000000..c0da6fbb045 --- /dev/null +++ b/queue-4.4/crypto-algif_skcipher-use-zero_or_null_ptr-in-skcipher_recvmsg_async.patch @@ -0,0 +1,58 @@ +From yangerkun@huawei.com Tue Mar 10 13:13:31 2020 +From: yangerkun +Date: Thu, 5 Mar 2020 16:57:55 +0800 +Subject: crypto: algif_skcipher - use ZERO_OR_NULL_PTR in skcipher_recvmsg_async +To: , +Cc: , , +Message-ID: <20200305085755.22730-1-yangerkun@huawei.com> + +From: yangerkun + +Nowdays, we trigger a oops: +... +kasan: GPF could be caused by NULL-ptr deref or user memory accessgeneral protection fault: 0000 [#1] SMP KASAN +... +Call Trace: + [] skcipher_recvmsg_async+0x3f1/0x1400 x86/../crypto/algif_skcipher.c:543 + [] skcipher_recvmsg+0x93/0x7f0 x86/../crypto/algif_skcipher.c:723 + [] sock_recvmsg_nosec x86/../net/socket.c:702 [inline] + [] sock_recvmsg x86/../net/socket.c:710 [inline] + [] sock_recvmsg+0x94/0xc0 x86/../net/socket.c:705 + [] sock_read_iter+0x27b/0x3a0 x86/../net/socket.c:787 + [] aio_run_iocb+0x21b/0x7a0 x86/../fs/aio.c:1520 + [] io_submit_one x86/../fs/aio.c:1630 [inline] + [] do_io_submit+0x6b9/0x10b0 x86/../fs/aio.c:1688 + [] SYSC_io_submit x86/../fs/aio.c:1713 [inline] + [] SyS_io_submit+0x2d/0x40 x86/../fs/aio.c:1710 + [] tracesys_phase2+0x90/0x95 + +In skcipher_recvmsg_async, we use '!sreq->tsg' to determine does we +calloc fail. However, kcalloc may return ZERO_SIZE_PTR, and with this, +the latter sg_init_table will trigger the bug. Fix it be use ZERO_OF_NULL_PTR. + +This function was introduced with ' commit a596999b7ddf ("crypto: +algif - change algif_skcipher to be asynchronous")', and has been removed +with 'commit e870456d8e7c ("crypto: algif_skcipher - overhaul memory +management")'. + +Reported-by: Hulk Robot +Signed-off-by: yangerkun +Signed-off-by: Greg Kroah-Hartman +--- + crypto/algif_skcipher.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +v1->v2: +update the commit message + +--- a/crypto/algif_skcipher.c ++++ b/crypto/algif_skcipher.c +@@ -538,7 +538,7 @@ static int skcipher_recvmsg_async(struct + lock_sock(sk); + tx_nents = skcipher_all_sg_nents(ctx); + sreq->tsg = kcalloc(tx_nents, sizeof(*sg), GFP_KERNEL); +- if (unlikely(!sreq->tsg)) ++ if (unlikely(ZERO_OR_NULL_PTR(sreq->tsg))) + goto unlock; + sg_init_table(sreq->tsg, tx_nents); + memcpy(iv, ctx->iv, ivsize); diff --git a/queue-4.4/dm-cache-fix-a-crash-due-to-incorrect-work-item-cancelling.patch b/queue-4.4/dm-cache-fix-a-crash-due-to-incorrect-work-item-cancelling.patch new file mode 100644 index 00000000000..0dd1e25dbc5 --- /dev/null +++ b/queue-4.4/dm-cache-fix-a-crash-due-to-incorrect-work-item-cancelling.patch @@ -0,0 +1,51 @@ +From 7cdf6a0aae1cccf5167f3f04ecddcf648b78e289 Mon Sep 17 00:00:00 2001 +From: Mikulas Patocka +Date: Wed, 19 Feb 2020 10:25:45 -0500 +Subject: dm cache: fix a crash due to incorrect work item cancelling + +From: Mikulas Patocka + +commit 7cdf6a0aae1cccf5167f3f04ecddcf648b78e289 upstream. + +The crash can be reproduced by running the lvm2 testsuite test +lvconvert-thin-external-cache.sh for several minutes, e.g.: + while :; do make check T=shell/lvconvert-thin-external-cache.sh; done + +The crash happens in this call chain: +do_waker -> policy_tick -> smq_tick -> end_hotspot_period -> clear_bitset +-> memset -> __memset -- which accesses an invalid pointer in the vmalloc +area. + +The work entry on the workqueue is executed even after the bitmap was +freed. The problem is that cancel_delayed_work doesn't wait for the +running work item to finish, so the work item can continue running and +re-submitting itself even after cache_postsuspend. In order to make sure +that the work item won't be running, we must use cancel_delayed_work_sync. + +Also, change flush_workqueue to drain_workqueue, so that if some work item +submits itself or another work item, we are properly waiting for both of +them. + +Fixes: c6b4fcbad044 ("dm: add cache target") +Cc: stable@vger.kernel.org # v3.9 +Signed-off-by: Mikulas Patocka +Signed-off-by: Mike Snitzer +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/md/dm-cache-target.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/md/dm-cache-target.c ++++ b/drivers/md/dm-cache-target.c +@@ -2193,8 +2193,8 @@ static void wait_for_migrations(struct c + + static void stop_worker(struct cache *cache) + { +- cancel_delayed_work(&cache->waker); +- flush_workqueue(cache->wq); ++ cancel_delayed_work_sync(&cache->waker); ++ drain_workqueue(cache->wq); + } + + static void requeue_deferred_cells(struct cache *cache) diff --git a/queue-4.4/series b/queue-4.4/series index 5c5e2f4b7c2..384a49d9f4d 100644 --- a/queue-4.4/series +++ b/queue-4.4/series @@ -68,3 +68,5 @@ arm-imx-build-v7_cpu_resume-unconditionally.patch hwmon-adt7462-fix-an-error-return-in-adt7462_reg_volt.patch dmaengine-coh901318-fix-a-double-lock-bug-in-dma_tc_handle.patch powerpc-fix-hardware-pmu-exception-bug-on-powervm-compatibility-mode-systems.patch +dm-cache-fix-a-crash-due-to-incorrect-work-item-cancelling.patch +crypto-algif_skcipher-use-zero_or_null_ptr-in-skcipher_recvmsg_async.patch