[syzbot] [kernel?] general protection fault in account_kernel_stack (3)

[syzbot] [kernel?] general protection fault in account_kernel_stack (3)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    f44d154d6e3d Merge tag 'soc-fixes-6.13' of git://git.kerne..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=105e27e8580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=c22efbd20f8da769
dashboard link: https://syzkaller.appspot.com/bug?extid=ff4aab278fa7e27e0f9e
compiler:       gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=15cb02df980000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=13cb02df980000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/129158790532/disk-f44d154d.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/4893f23f2c39/vmlinux-f44d154d.xz
kernel image: https://storage.googleapis.com/syzbot-assets/b12b565fb71e/bzImage-f44d154d.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+ff4aab278fa7e27e0f9e@syzkaller.appspotmail.com

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 0 UID: 0 PID: 18226 Comm: syz-executor293 Not tainted 6.13.0-rc3-syzkaller-00017-gf44d154d6e3d #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024
RIP: 0010:_compound_head include/linux/page-flags.h:242 [inline]
RIP: 0010:mod_lruvec_page_state include/linux/vmstat.h:563 [inline]
RIP: 0010:account_kernel_stack+0x100/0x2e0 kernel/fork.c:546
Code: 00 49 8b 47 20 48 8d 2c d8 48 89 e8 48 c1 e8 03 42 80 3c 20 00 0f 85 be 01 00 00 48 8b 6d 00 48 8d 7d 08 48 89 f8 48 c1 e8 03 <42> 80 3c 20 00 0f 85 9a 01 00 00 4c 8b 6d 08 31 ff 4d 89 ee 41 83
RSP: 0018:ffffc9001103fd78 EFLAGS: 00010202
RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffff888078768000 RSI: ffffffff815906c9 RDI: 0000000000000008
RBP: 0000000000000000 R08: 0000000000000000 R09: ffffed100f0ed138
R10: ffff8880787689c3 R11: 0000000000000000 R12: dffffc0000000000
R13: dffffc0000000000 R14: 1ffff11003e74fc4 R15: ffff88801f3a7e00
FS:  0000000000000000(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f040152f190 CR3: 000000000db7e000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 exit_task_stack_account+0x23/0xf0 kernel/fork.c:559
 do_exit+0x1c8a/0x2d70 kernel/exit.c:979
 do_group_exit+0xd3/0x2a0 kernel/exit.c:1087
 __do_sys_exit_group kernel/exit.c:1098 [inline]
 __se_sys_exit_group kernel/exit.c:1096 [inline]
 __x64_sys_exit_group+0x3e/0x50 kernel/exit.c:1096
 x64_sys_call+0x151f/0x1720 arch/x86/include/generated/asm/syscalls_64.h:232
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f04014b3d69
Code: Unable to access opcode bytes at 0x7f04014b3d3f.
RSP: 002b:00007fffbefe3918 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f04014b3d69
RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000
RBP: 00007f040152d2b0 R08: ffffffffffffffb8 R09: 00007fffbefe39a8
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f040152d2b0
R13: 0000000000000000 R14: 00007f040152ed80 R15: 00007f040147d5d0
 </TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:_compound_head include/linux/page-flags.h:242 [inline]
RIP: 0010:mod_lruvec_page_state include/linux/vmstat.h:563 [inline]
RIP: 0010:account_kernel_stack+0x100/0x2e0 kernel/fork.c:546
Code: 00 49 8b 47 20 48 8d 2c d8 48 89 e8 48 c1 e8 03 42 80 3c 20 00 0f 85 be 01 00 00 48 8b 6d 00 48 8d 7d 08 48 89 f8 48 c1 e8 03 <42> 80 3c 20 00 0f 85 9a 01 00 00 4c 8b 6d 08 31 ff 4d 89 ee 41 83
RSP: 0018:ffffc9001103fd78 EFLAGS: 00010202
RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffff888078768000 RSI: ffffffff815906c9 RDI: 0000000000000008
RBP: 0000000000000000 R08: 0000000000000000 R09: ffffed100f0ed138
R10: ffff8880787689c3 R11: 0000000000000000 R12: dffffc0000000000
R13: dffffc0000000000 R14: 1ffff11003e74fc4 R15: ffff88801f3a7e00
FS:  0000000000000000(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f040152f190 CR3: 000000007ecd0000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
----------------
Code disassembly (best guess):
   0:	00 49 8b             	add    %cl,-0x75(%rcx)
   3:	47 20 48 8d          	rex.RXB and %r9b,-0x73(%r8)
   7:	2c d8                	sub    $0xd8,%al
   9:	48 89 e8             	mov    %rbp,%rax
   c:	48 c1 e8 03          	shr    $0x3,%rax
  10:	42 80 3c 20 00       	cmpb   $0x0,(%rax,%r12,1)
  15:	0f 85 be 01 00 00    	jne    0x1d9
  1b:	48 8b 6d 00          	mov    0x0(%rbp),%rbp
  1f:	48 8d 7d 08          	lea    0x8(%rbp),%rdi
  23:	48 89 f8             	mov    %rdi,%rax
  26:	48 c1 e8 03          	shr    $0x3,%rax
* 2a:	42 80 3c 20 00       	cmpb   $0x0,(%rax,%r12,1) <-- trapping instruction
  2f:	0f 85 9a 01 00 00    	jne    0x1cf
  35:	4c 8b 6d 08          	mov    0x8(%rbp),%r13
  39:	31 ff                	xor    %edi,%edi
  3b:	4d 89 ee             	mov    %r13,%r14
  3e:	41                   	rex.B
  3f:	83                   	.byte 0x83


---
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.

If the report is already addressed, 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 overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

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

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

[PATCH] nvmet: Don't overflow subsysnqn

[Leo Stone]

nvmet_root_discovery_nqn_store treats the subsysnqn string like a fixed
size buffer, even though it is dynamically allocated to the size of the
string.

Create a new string with kstrdup instead of using the old buffer.

Reported-by: syzbot+ff4aab278fa7e27e0f9e@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=ff4aab278fa7e27e0f9e
Fixes: 95409e277d83 ("nvmet: implement unique discovery NQN")
Signed-off-by: Leo Stone <leocstone@gmail.com>
---
 drivers/nvme/target/configfs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/nvme/target/configfs.c b/drivers/nvme/target/configfs.c
index eeee9e9b854c..3fa25f9f7d92 100644
--- a/drivers/nvme/target/configfs.c
+++ b/drivers/nvme/target/configfs.c
@@ -2271,8 +2271,8 @@ static ssize_t nvmet_root_discovery_nqn_store(struct config_item *item,
 			return -EINVAL;
 		}
 	}
-	memset(nvmet_disc_subsys->subsysnqn, 0, NVMF_NQN_FIELD_LEN);
-	memcpy(nvmet_disc_subsys->subsysnqn, page, len);
+	kfree(nvmet_disc_subsys->subsysnqn);
+	nvmet_disc_subsys->subsysnqn = kstrdup(page, GFP_KERNEL);
 	up_write(&nvmet_config_sem);
 
 	return len;
-- 
2.43.0

Re: [PATCH] nvmet: Don't overflow subsysnqn

[Christoph Hellwig]

On Tue, Dec 17, 2024 at 04:59:10PM -0800, Leo Stone wrote:
> nvmet_root_discovery_nqn_store treats the subsysnqn string like a fixed
> size buffer, even though it is dynamically allocated to the size of the
> string.
> 
> Create a new string with kstrdup instead of using the old buffer.
> 
> Reported-by: syzbot+ff4aab278fa7e27e0f9e@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=ff4aab278fa7e27e0f9e
> Fixes: 95409e277d83 ("nvmet: implement unique discovery NQN")
> Signed-off-by: Leo Stone <leocstone@gmail.com>
> ---
>  drivers/nvme/target/configfs.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/nvme/target/configfs.c b/drivers/nvme/target/configfs.c
> index eeee9e9b854c..3fa25f9f7d92 100644
> --- a/drivers/nvme/target/configfs.c
> +++ b/drivers/nvme/target/configfs.c
> @@ -2271,8 +2271,8 @@ static ssize_t nvmet_root_discovery_nqn_store(struct config_item *item,
>  			return -EINVAL;
>  		}
>  	}
> -	memset(nvmet_disc_subsys->subsysnqn, 0, NVMF_NQN_FIELD_LEN);
> -	memcpy(nvmet_disc_subsys->subsysnqn, page, len);
> +	kfree(nvmet_disc_subsys->subsysnqn);
> +	nvmet_disc_subsys->subsysnqn = kstrdup(page, GFP_KERNEL);

This needs error handling, pobably best done by using a local
variable for the new allocation, which would also help to keep it
outside the lock.