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 <[email protected]>
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: [email protected]
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 [email protected].
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
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;
}
Hello,
syzbot has tested the proposed patch and the reproducer did not trigger any issue:
Reported-and-tested-by: [email protected]
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.
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 <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git main
commit c2996e733d4f2d93bdc0fed74022da082b2e6784
Author: David Howells <[email protected]>
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: [email protected]
Link: https://lore.kernel.org/r/[email protected]/
Reported-by: [email protected]
Link: https://lore.kernel.org/r/[email protected]/
Reported-by: [email protected]
Link: https://lore.kernel.org/r/[email protected]/
Reported-by: [email protected]
Link: https://lore.kernel.org/r/[email protected]/
Signed-off-by: David Howells <[email protected]>
cc: Herbert Xu <[email protected]>
cc: "David S. Miller" <[email protected]>
cc: Eric Dumazet <[email protected]>
cc: Jakub Kicinski <[email protected]>
cc: Paolo Abeni <[email protected]>
cc: Jens Axboe <[email protected]>
cc: Matthew Wilcox <[email protected]>
cc: [email protected]
cc: [email protected]
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;
}
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;
}
Hello,
syzbot has tested the proposed patch and the reproducer did not trigger any issue:
Reported-and-tested-by: [email protected]
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.