drop queue-4.14/crypto-algif_skcipher-use-zero_or_null_ptr-in-skcipher_recvmsg_async...

diff --git a/queue-4.14/crypto-algif_skcipher-use-zero_or_null_ptr-in-skcipher_recvmsg_async.patch b/queue-4.14/crypto-algif_skcipher-use-zero_or_null_ptr-in-skcipher_recvmsg_async.patch
deleted file mode 100644 (file)
index 2a03a80..0000000
--- a/queue-4.14/crypto-algif_skcipher-use-zero_or_null_ptr-in-skcipher_recvmsg_async.patch
+++ /dev/null
@@ -1,63 +0,0 @@
-From yangerkun@huawei.com  Tue Mar 10 13:13:31 2020
-From: yangerkun <yangerkun@huawei.com>
-Date: Thu, 5 Mar 2020 16:57:55 +0800
-Subject: crypto: algif_skcipher - use ZERO_OR_NULL_PTR in skcipher_recvmsg_async
-To: <gregkh@linuxfoundation.org>, <herbert@gondor.apana.org.au>
-Cc: <stable@vger.kernel.org>, <linux-crypto@vger.kernel.org>, <yangerkun@huawei.com>
-Message-ID: <20200305085755.22730-1-yangerkun@huawei.com>
-
-From: yangerkun <yangerkun@huawei.com>
-
-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:
- [<ffffffff81a26fb1>] skcipher_recvmsg_async+0x3f1/0x1400 x86/../crypto/algif_skcipher.c:543
- [<ffffffff81a28053>] skcipher_recvmsg+0x93/0x7f0 x86/../crypto/algif_skcipher.c:723
- [<ffffffff823e43a4>] sock_recvmsg_nosec x86/../net/socket.c:702 [inline]
- [<ffffffff823e43a4>] sock_recvmsg x86/../net/socket.c:710 [inline]
- [<ffffffff823e43a4>] sock_recvmsg+0x94/0xc0 x86/../net/socket.c:705
- [<ffffffff823e464b>] sock_read_iter+0x27b/0x3a0 x86/../net/socket.c:787
- [<ffffffff817f479b>] aio_run_iocb+0x21b/0x7a0 x86/../fs/aio.c:1520
- [<ffffffff817f57c9>] io_submit_one x86/../fs/aio.c:1630 [inline]
- [<ffffffff817f57c9>] do_io_submit+0x6b9/0x10b0 x86/../fs/aio.c:1688
- [<ffffffff817f902d>] SYSC_io_submit x86/../fs/aio.c:1713 [inline]
- [<ffffffff817f902d>] SyS_io_submit+0x2d/0x40 x86/../fs/aio.c:1710
- [<ffffffff828b33c3>] 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 <hulkci@huawei.com>
-Signed-off-by: yangerkun <yangerkun@huawei.com>
-Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----
- crypto/algif_skcipher.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-v1->v2:
-update the commit message
-
-diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
-index d12782dc9683..9bd4691cc5c5 100644
---- a/crypto/algif_skcipher.c
-+++ b/crypto/algif_skcipher.c
-@@ -538,7 +538,7 @@ static int skcipher_recvmsg_async(struct socket *sock, struct msghdr *msg,
-       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);
--- 
-2.17.2
-

diff --git a/queue-4.14/series b/queue-4.14/series
index abd69ac04ea415061832e6aa0db4ad3ca57e8790..600eae3f96b6d7a0332d60f5e74bc67696541ce1 100644 (file)
--- a/queue-4.14/series
+++ b/queue-4.14/series
@@ -124,4 +124,3 @@ 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-integrity-fix-a-deadlock-due-to-offloading-to-an-incorrect-workqueue.patch
 xhci-handle-port-status-events-for-removed-usb3-hcd.patch
-crypto-algif_skcipher-use-zero_or_null_ptr-in-skcipher_recvmsg_async.patch