[syzbot] [crypto?] general protection fault in shash_async_final

[syzbot] [crypto?] general protection fault in shash_async_final

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    37ff78e977f1 mlxsw: spectrum_nve_vxlan: Fix unsupported fl..
git tree:       net-next
console+strace: https://syzkaller.appspot.com/x/log.txt?x=13b26ef1280000
kernel config:  https://syzkaller.appspot.com/x/.config?x=526f919910d4a671
dashboard link: https://syzkaller.appspot.com/bug?extid=13a08c0bf4d212766c3c
compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=165dc395280000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=13f9172b280000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/41e829152d3c/disk-37ff78e9.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/a594b97acb02/vmlinux-37ff78e9.xz
kernel image: https://storage.googleapis.com/syzbot-assets/b41140b53372/bzImage-37ff78e9.xz

The issue was bisected to:

commit c662b043cdca89bf0f03fc37251000ac69a3a548
Author: David Howells <dhowells@redhat.com>
Date:   Tue Jun 6 13:08:56 2023 +0000

    crypto: af_alg/hash: Support MSG_SPLICE_PAGES

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=14a2def1280000
final oops:     https://syzkaller.appspot.com/x/report.txt?x=16a2def1280000
console output: https://syzkaller.appspot.com/x/log.txt?x=12a2def1280000

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+13a08c0bf4d212766c3c@syzkaller.appspotmail.com
Fixes: c662b043cdca ("crypto: af_alg/hash: Support MSG_SPLICE_PAGES")

general protection fault, probably for non-canonical address 0xdffffc0000000004: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]
CPU: 1 PID: 5003 Comm: syz-executor289 Not tainted 6.4.0-rc5-syzkaller-00859-g37ff78e977f1 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023
RIP: 0010:crypto_shash_alg include/crypto/hash.h:827 [inline]
RIP: 0010:crypto_shash_final crypto/shash.c:171 [inline]
RIP: 0010:shash_async_final+0x6d/0x150 crypto/shash.c:319
Code: 4c 89 e2 48 c1 ea 03 80 3c 02 00 0f 85 d5 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 5b 50 48 8d 7b 20 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 a8 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b
RSP: 0018:ffffc900039af8f8 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000004 RSI: ffffffff83df3032 RDI: 0000000000000020
RBP: 0000000000000010 R08: 0000000000000007 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000655 R12: ffff88801f6c0af8
R13: 0000000000000010 R14: ffff888015fd1000 R15: ffff88801f6c0a38
FS:  00005555561eb300(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000107b3a8 CR3: 0000000078da9000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 crypto_ahash_op crypto/ahash.c:303 [inline]
 crypto_ahash_op crypto/ahash.c:292 [inline]
 crypto_ahash_final+0xed/0x1e0 crypto/ahash.c:316
 hash_recvmsg+0x2c6/0xa80 crypto/algif_hash.c:248
 hash_recvmsg_nokey+0x69/0x90 crypto/algif_hash.c:404
 sock_recvmsg_nosec net/socket.c:1019 [inline]
 sock_recvmsg+0xe2/0x160 net/socket.c:1040
 ____sys_recvmsg+0x210/0x5a0 net/socket.c:2724
 ___sys_recvmsg+0xf2/0x180 net/socket.c:2766
 do_recvmmsg+0x25e/0x6f0 net/socket.c:2860
 __sys_recvmmsg net/socket.c:2939 [inline]
 __do_sys_recvmmsg net/socket.c:2962 [inline]
 __se_sys_recvmmsg net/socket.c:2955 [inline]
 __x64_sys_recvmmsg+0x20f/0x260 net/socket.c:2955
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f030b570c49
Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffd507d5968 EFLAGS: 00000246 ORIG_RAX: 000000000000012b
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f030b570c49
RDX: 000000000000049f RSI: 0000000020006100 RDI: 0000000000000004
RBP: 00007f030b534df0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f030b534e80
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
 </TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:crypto_shash_alg include/crypto/hash.h:827 [inline]
RIP: 0010:crypto_shash_final crypto/shash.c:171 [inline]
RIP: 0010:shash_async_final+0x6d/0x150 crypto/shash.c:319
Code: 4c 89 e2 48 c1 ea 03 80 3c 02 00 0f 85 d5 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 5b 50 48 8d 7b 20 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 a8 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b
RSP: 0018:ffffc900039af8f8 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000004 RSI: ffffffff83df3032 RDI: 0000000000000020
RBP: 0000000000000010 R08: 0000000000000007 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000655 R12: ffff88801f6c0af8
R13: 0000000000000010 R14: ffff888015fd1000 R15: ffff88801f6c0a38
FS:  00005555561eb300(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000107b3a8 CR3: 0000000078da9000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
----------------
Code disassembly (best guess):
   0:	4c 89 e2             	mov    %r12,%rdx
   3:	48 c1 ea 03          	shr    $0x3,%rdx
   7:	80 3c 02 00          	cmpb   $0x0,(%rdx,%rax,1)
   b:	0f 85 d5 00 00 00    	jne    0xe6
  11:	48 b8 00 00 00 00 00 	movabs $0xdffffc0000000000,%rax
  18:	fc ff df
  1b:	48 8b 5b 50          	mov    0x50(%rbx),%rbx
  1f:	48 8d 7b 20          	lea    0x20(%rbx),%rdi
  23:	48 89 fa             	mov    %rdi,%rdx
  26:	48 c1 ea 03          	shr    $0x3,%rdx
* 2a:	80 3c 02 00          	cmpb   $0x0,(%rdx,%rax,1) <-- trapping instruction
  2e:	0f 85 a8 00 00 00    	jne    0xdc
  34:	48 b8 00 00 00 00 00 	movabs $0xdffffc0000000000,%rax
  3b:	fc ff df
  3e:	48                   	rex.W
  3f:	8b                   	.byte 0x8b


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection

If the bug is already fixed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to change bug's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the bug is a duplicate of another bug, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

Re: [syzbot] [crypto?] general protection fault in shash_async_final

[David Howells]

Here's a reduced testcase for this.  The key seems to be passing MSG_MORE to
sendmsg() and then not following up with more data before calling recvmsg().
Apart from not oopsing, I wonder what the behaviour should be here?  Should
recvmsg() return an error (EAGAIN or ENODATA maybe) or should it close the
existing operation?

David
---
// https://syzkaller.appspot.com/bug?id=f5d9d503fe959e3b605abdaeedb39b072556281a
// autogenerated by syzkaller (https://github.com/google/syzkaller)
#define _GNU_SOURCE
#include <endian.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/socket.h>
#include <unistd.h>
#include <linux/if_alg.h>

#define OSERROR(R, S) do { if ((long)(R) == -1L) { perror((S)); exit(1); } } while(0)

int main(void)
{
	struct sockaddr_alg salg;
	struct msghdr msg;
	int algfd, hashfd, res;

	algfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
	OSERROR(algfd, "socket");

	memset(&salg, 0, sizeof(salg));
	salg.salg_family = AF_ALG;
	strcpy(salg.salg_type, "hash");
	strcpy(salg.salg_name, "digest_null-generic");
	res = bind(algfd, (struct sockaddr *)&salg, sizeof(salg));
	OSERROR(res, "bind/alg");

	hashfd = accept4(algfd, NULL, 0, 0);
	OSERROR(hashfd, "accept/alg");

	res = setsockopt(3, SOL_ALG, ALG_SET_KEY, NULL, 0);
	OSERROR(res, "setsockopt/ALG_SET_KEY");

	memset(&msg, 0, sizeof(msg));
	res = sendmsg(hashfd, &msg, MSG_MORE);
	OSERROR(res, "sendmsg");

	res = recvmsg(hashfd, &msg, 0);
	OSERROR(res, "recvmsg");
	return 0;
}

Re: [syzbot] [crypto?] general protection fault in shash_async_final

[Herbert Xu]

On Wed, Jun 14, 2023 at 12:25:14PM +0100, David Howells wrote:
> Here's a reduced testcase for this.  The key seems to be passing MSG_MORE to
> sendmsg() and then not following up with more data before calling recvmsg().
> Apart from not oopsing, I wonder what the behaviour should be here?  Should
> recvmsg() return an error (EAGAIN or ENODATA maybe) or should it close the
> existing operation?

On send if MSG_MORE is set then we don't finalise the hash.

If the user calls recvmsg while the hash hasn't been finalised, then
we will force finalisation (thus rendering the last MSG_MORE moot).

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [syzbot] [crypto?] general protection fault in shash_async_final

[David Howells]

Hi Herbert,

Here's a slightly more comprehensive test program for the hashing code to
exercise some combinations of sendmsg, sendmsg+MSG_MORE and recvmsg.

David
---
#define _GNU_SOURCE
#include <endian.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/socket.h>
#include <unistd.h>
#include <linux/if_alg.h>

#define OSERROR(R, S) do { if ((long)(R) == -1L) { perror((S)); exit(1); } } while(0)

static int hashfd;
static unsigned char buf[1024], sbuf[1024];
static const unsigned char no_zeros[2]  = { 0xe3, 0xb0 };
static const unsigned char one_zero[2]  = { 0x6e, 0x34 };
static const unsigned char two_zeros[2] = { 0x96, 0xa2 };

static void do_send(unsigned int n, unsigned int flags)
{
	struct msghdr msg;
	struct iovec iov[1];
	int res;

	memset(&msg, 0, sizeof(msg));
	iov[0].iov_base = sbuf;
	iov[0].iov_len = n;
	msg.msg_iov = iov;
	msg.msg_iovlen = 1;
	res = sendmsg(hashfd, &msg, flags);
	OSERROR(res, "sendmsg");
}

static void do_recv(unsigned int ix, const unsigned char r[2])
{
	struct msghdr msg;
	struct iovec iov[1];
	int res, i;

	memset(&msg, 0, sizeof(msg));
	iov[0].iov_base = buf;
	iov[0].iov_len = sizeof(buf);
	msg.msg_iov = iov;
	msg.msg_iovlen = 1;
	res = recvmsg(hashfd, &msg, 0);
	OSERROR(res, "recvmsg");

	printf("%3u: ", ix);
	for (i = 0; i < res; i++)
		 printf("%02x", buf[i]);
	printf("\n");

	if (buf[0] != r[0] || buf[1] != r[1])
		 fprintf(stderr, "     ^ Bad result!\n");
}

int main(void)
{
	struct sockaddr_alg salg;
	int algfd, res;

	algfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
	OSERROR(algfd, "socket");

	memset(&salg, 0, sizeof(salg));
	salg.salg_family = AF_ALG;
	strcpy(salg.salg_type, "hash");
	strcpy(salg.salg_name, "sha256");
	res = bind(algfd, (struct sockaddr *)&salg, sizeof(salg));
	OSERROR(res, "bind/alg");

	hashfd = accept4(algfd, NULL, 0, 0);
	OSERROR(hashfd, "accept/alg");

	//res = setsockopt(3, SOL_ALG, ALG_SET_KEY, NULL, 0);
	//OSERROR(res, "setsockopt/ALG_SET_KEY");
	
	/* Test no send */
	do_recv(__LINE__, no_zeros);

	/* Test single send of 0 */
	do_send(0, 0);
	do_recv(__LINE__, no_zeros);

	do_send(0, MSG_MORE);
	do_recv(__LINE__, no_zeros);

	/* Test single send of 1 */
	do_send(1, 0);
	do_recv(__LINE__, one_zero);

	do_send(1, MSG_MORE);
	do_recv(__LINE__, one_zero);

	/* Test single send of 2 */
	do_send(2, 0);
	do_recv(__LINE__, two_zeros);

	do_send(2, MSG_MORE);
	do_recv(__LINE__, two_zeros);

	/* Test two sends of 1 */
	do_send(1, 0);
	do_send(1, 0);
	do_recv(__LINE__, one_zero);

	do_send(1, 0);
	do_send(1, MSG_MORE);
	do_recv(__LINE__, one_zero);

	do_send(1, MSG_MORE);
	do_send(1, 0);
	do_recv(__LINE__, two_zeros);

	do_send(1, MSG_MORE);
	do_send(1, MSG_MORE);
	do_recv(__LINE__, two_zeros);

	/* Test send of 0 then send of 2 */
	do_send(0, 0);
	do_send(2, 0);
	do_recv(__LINE__, two_zeros);

	do_send(0, 0);
	do_send(2, MSG_MORE);
	do_recv(__LINE__, two_zeros);

	do_send(0, MSG_MORE);
	do_send(2, 0);
	do_recv(__LINE__, two_zeros);

	do_send(0, MSG_MORE);
	do_send(2, MSG_MORE);
	do_recv(__LINE__, two_zeros);

	/* Test send of 2 then send of 0 */
	do_send(2, 0);
	do_send(0, 0);
	do_recv(__LINE__, no_zeros);

	do_send(2, 0);
	do_send(0, MSG_MORE);
	do_recv(__LINE__, no_zeros);

	do_send(2, MSG_MORE);
	do_send(0, 0);
	do_recv(__LINE__, two_zeros);

	do_send(2, MSG_MORE);
	do_send(0, MSG_MORE);
	do_recv(__LINE__, two_zeros);

	return 0;
}

Re: [syzbot] [crypto?] general protection fault in shash_async_final

[David Howells]

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git main

    crypto: af_alg/hash: Fix recvmsg() after sendmsg(MSG_MORE)
    
    If an AF_ALG socket bound to a hashing algorithm is sent a zero-length
    message with MSG_MORE set and then recvmsg() is called without first
    sending another message without MSG_MORE set to end the operation, an oops
    will occur because the crypto context and result doesn't now get set up in
    advance because hash_sendmsg() now defers that as long as possible in the
    hope that it can use crypto_ahash_digest() - and then because the message
    is zero-length, it the data wrangling loop is skipped.
    
    Fix this by always making a pass of the loop, even in the case that no data
    is provided to the sendmsg().
    
    Fix also extract_iter_to_sg() to handle a zero-length iterator by returning
    0 immediately.
    
    Whilst we're at it, remove the code to create a kvmalloc'd scatterlist if
    we get more than ALG_MAX_PAGES - this shouldn't happen.
    
    Fixes: c662b043cdca ("crypto: af_alg/hash: Support MSG_SPLICE_PAGES")
    Reported-by: syzbot+13a08c0bf4d212766c3c@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/r/000000000000b928f705fdeb873a@google.com/
    Signed-off-by: David Howells <dhowells@redhat.com>
    cc: Herbert Xu <herbert@gondor.apana.org.au>
    cc: "David S. Miller" <davem@davemloft.net>
    cc: Eric Dumazet <edumazet@google.com>
    cc: Jakub Kicinski <kuba@kernel.org>
    cc: Paolo Abeni <pabeni@redhat.com>
    cc: Jens Axboe <axboe@kernel.dk>
    cc: Matthew Wilcox <willy@infradead.org>
    cc: linux-crypto@vger.kernel.org
    cc: netdev@vger.kernel.org

diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
index dfb048cefb60..1176533a55c9 100644
--- a/crypto/algif_hash.c
+++ b/crypto/algif_hash.c
@@ -83,26 +83,14 @@ static int hash_sendmsg(struct socket *sock, struct msghdr *msg,
 
 	ctx->more = false;
 
-	while (msg_data_left(msg)) {
+	do {
 		ctx->sgl.sgt.sgl = ctx->sgl.sgl;
 		ctx->sgl.sgt.nents = 0;
 		ctx->sgl.sgt.orig_nents = 0;
 
 		err = -EIO;
 		npages = iov_iter_npages(&msg->msg_iter, max_pages);
-		if (npages == 0)
-			goto unlock_free;
-
-		if (npages > ARRAY_SIZE(ctx->sgl.sgl)) {
-			err = -ENOMEM;
-			ctx->sgl.sgt.sgl =
-				kvmalloc(array_size(npages,
-						    sizeof(*ctx->sgl.sgt.sgl)),
-					 GFP_KERNEL);
-			if (!ctx->sgl.sgt.sgl)
-				goto unlock_free;
-		}
-		sg_init_table(ctx->sgl.sgl, npages);
+		sg_init_table(ctx->sgl.sgl, max_t(size_t, npages, 1));
 
 		ctx->sgl.need_unpin = iov_iter_extract_will_pin(&msg->msg_iter);
 
@@ -111,7 +99,8 @@ static int hash_sendmsg(struct socket *sock, struct msghdr *msg,
 		if (err < 0)
 			goto unlock_free;
 		len = err;
-		sg_mark_end(ctx->sgl.sgt.sgl + ctx->sgl.sgt.nents - 1);
+		if (len > 0)
+			sg_mark_end(ctx->sgl.sgt.sgl + ctx->sgl.sgt.nents - 1);
 
 		if (!msg_data_left(msg)) {
 			err = hash_alloc_result(sk, ctx);
@@ -148,7 +137,7 @@ static int hash_sendmsg(struct socket *sock, struct msghdr *msg,
 
 		copied += len;
 		af_alg_free_sg(&ctx->sgl);
-	}
+	} while (msg_data_left(msg));
 
 	ctx->more = msg->msg_flags & MSG_MORE;
 	err = 0;
diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index e97d7060329e..77a7b18ee751 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -1340,7 +1340,7 @@ ssize_t extract_iter_to_sg(struct iov_iter *iter, size_t maxsize,
 			   struct sg_table *sgtable, unsigned int sg_max,
 			   iov_iter_extraction_t extraction_flags)
 {
-	if (maxsize == 0)
+	if (!maxsize || !iter->count)
 		return 0;
 
 	switch (iov_iter_type(iter)) {

Re: [syzbot] [crypto?] general protection fault in shash_async_final

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-and-tested-by: syzbot+13a08c0bf4d212766c3c@syzkaller.appspotmail.com

Tested on:

commit:         fa0e21fa rtnetlink: extend RTEXT_FILTER_SKIP_STATS to ..
git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git main
console output: https://syzkaller.appspot.com/x/log.txt?x=17790627280000
kernel config:  https://syzkaller.appspot.com/x/.config?x=526f919910d4a671
dashboard link: https://syzkaller.appspot.com/bug?extid=13a08c0bf4d212766c3c
compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
patch:          https://syzkaller.appspot.com/x/patch.diff?x=14c0019d280000

Note: testing is done by a robot and is best-effort only.

Re: [syzbot] [crypto?] general protection fault in shash_async_final

[David Howells]

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git main

commit c2996e733d4f2d93bdc0fed74022da082b2e6784
Author: David Howells <dhowells@redhat.com>
Date:   Wed Jun 14 13:33:04 2023 +0100

    crypto: af_alg/hash: Fix recvmsg() after sendmsg(MSG_MORE)
    
    If an AF_ALG socket bound to a hashing algorithm is sent a zero-length
    message with MSG_MORE set and then recvmsg() is called without first
    sending another message without MSG_MORE set to end the operation, an oops
    will occur because the crypto context and result doesn't now get set up in
    advance because hash_sendmsg() now defers that as long as possible in the
    hope that it can use crypto_ahash_digest() - and then because the message
    is zero-length, it the data wrangling loop is skipped.
    
    Fix this by handling zero-length sends at the top of the hash_sendmsg()
    function.  If we're not continuing the previous sendmsg(), then just ignore
    the send (hash_recvmsg() will invent something when called); if we are
    continuing, then we finalise the request at this point if MSG_MORE is not
    set to get any error here, otherwise the send is of no effect and can be
    ignored.
    
    Whilst we're at it, remove the code to create a kvmalloc'd scatterlist if
    we get more than ALG_MAX_PAGES - this shouldn't happen.
    
    Fixes: c662b043cdca ("crypto: af_alg/hash: Support MSG_SPLICE_PAGES")
    Reported-by: syzbot+13a08c0bf4d212766c3c@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/r/000000000000b928f705fdeb873a@google.com/
    Reported-by: syzbot+14234ccf6d0ef629ec1a@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/r/000000000000c047db05fdeb8790@google.com/
    Reported-by: syzbot+4e2e47f32607d0f72d43@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/r/000000000000bcca3205fdeb87fb@google.com/
    Reported-by: syzbot+472626bb5e7c59fb768f@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/r/000000000000b55d8805fdeb8385@google.com/
    Signed-off-by: David Howells <dhowells@redhat.com>
    cc: Herbert Xu <herbert@gondor.apana.org.au>
    cc: "David S. Miller" <davem@davemloft.net>
    cc: Eric Dumazet <edumazet@google.com>
    cc: Jakub Kicinski <kuba@kernel.org>
    cc: Paolo Abeni <pabeni@redhat.com>
    cc: Jens Axboe <axboe@kernel.dk>
    cc: Matthew Wilcox <willy@infradead.org>
    cc: linux-crypto@vger.kernel.org
    cc: netdev@vger.kernel.org

diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
index dfb048cefb60..0ab43e149f0e 100644
--- a/crypto/algif_hash.c
+++ b/crypto/algif_hash.c
@@ -76,13 +76,30 @@ static int hash_sendmsg(struct socket *sock, struct msghdr *msg,
 
 	lock_sock(sk);
 	if (!continuing) {
-		if ((msg->msg_flags & MSG_MORE))
-			hash_free_result(sk, ctx);
+		/* Discard a previous request that wasn't marked MSG_MORE. */
+		hash_free_result(sk, ctx);
+		if (!msg_data_left(msg))
+			goto done; /* Zero-length; don't start new req */
 		need_init = true;
+	} else if (!msg_data_left(msg)) {
+		/*
+		 * No data - finalise the prev req if MSG_MORE so any error
+		 * comes out here.
+		 */
+		if (!(msg->msg_flags & MSG_MORE)) {
+			err = hash_alloc_result(sk, ctx);
+			if (err)
+				goto unlock_free;
+			ahash_request_set_crypt(&ctx->req, NULL,
+						ctx->result, 0);
+			err = crypto_wait_req(crypto_ahash_final(&ctx->req),
+					      &ctx->wait);
+			if (err)
+				goto unlock_free;
+		}
+		goto done_more;
 	}
 
-	ctx->more = false;
-
 	while (msg_data_left(msg)) {
 		ctx->sgl.sgt.sgl = ctx->sgl.sgl;
 		ctx->sgl.sgt.nents = 0;
@@ -93,15 +110,6 @@ static int hash_sendmsg(struct socket *sock, struct msghdr *msg,
 		if (npages == 0)
 			goto unlock_free;
 
-		if (npages > ARRAY_SIZE(ctx->sgl.sgl)) {
-			err = -ENOMEM;
-			ctx->sgl.sgt.sgl =
-				kvmalloc(array_size(npages,
-						    sizeof(*ctx->sgl.sgt.sgl)),
-					 GFP_KERNEL);
-			if (!ctx->sgl.sgt.sgl)
-				goto unlock_free;
-		}
 		sg_init_table(ctx->sgl.sgl, npages);
 
 		ctx->sgl.need_unpin = iov_iter_extract_will_pin(&msg->msg_iter);
@@ -150,7 +158,9 @@ static int hash_sendmsg(struct socket *sock, struct msghdr *msg,
 		af_alg_free_sg(&ctx->sgl);
 	}
 
+done_more:
 	ctx->more = msg->msg_flags & MSG_MORE;
+done:
 	err = 0;
 unlock:
 	release_sock(sk);
@@ -158,6 +168,8 @@ static int hash_sendmsg(struct socket *sock, struct msghdr *msg,
 
 unlock_free:
 	af_alg_free_sg(&ctx->sgl);
+	hash_free_result(sk, ctx);
+	ctx->more = false;
 	goto unlock;
 }
 

Re: [syzbot] [crypto?] general protection fault in shash_async_final

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-and-tested-by: syzbot+13a08c0bf4d212766c3c@syzkaller.appspotmail.com

Tested on:

commit:         97c5209b leds: trigger: netdev: uninitialized variable..
git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git main
console output: https://syzkaller.appspot.com/x/log.txt?x=159c4d9b280000
kernel config:  https://syzkaller.appspot.com/x/.config?x=526f919910d4a671
dashboard link: https://syzkaller.appspot.com/bug?extid=13a08c0bf4d212766c3c
compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
patch:          https://syzkaller.appspot.com/x/patch.diff?x=16962727280000

Note: testing is done by a robot and is best-effort only.