[syzbot] [serial?] KASAN: stack-out-of-bounds Read in sched_show_task

[syzbot] [serial?] KASAN: stack-out-of-bounds Read in sched_show_task

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    8eb8fe67e2c8 riscv: errata: fix T-Head dcache.cva encoding
git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes
console output: https://syzkaller.appspot.com/x/log.txt?x=1206d6c4680000
kernel config:  https://syzkaller.appspot.com/x/.config?x=89f0a88d4bc7f0f4
dashboard link: https://syzkaller.appspot.com/bug?extid=8d2757d62d403b2d9275
compiler:       riscv64-linux-gnu-gcc (Debian 12.2.0-13) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
userspace arch: riscv64
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=144d1154680000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=122a2a3c680000

Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/a741b348759c/non_bootable_disk-8eb8fe67.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/a41f94065e95/vmlinux-8eb8fe67.xz
kernel image: https://storage.googleapis.com/syzbot-assets/29db706d00c4/Image-8eb8fe67.xz

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

[<ffffffff8360b8b4>] context_switch kernel/sched/core.c:5382 [inline]
[<ffffffff8360b8b4>] __schedule+0x794/0x1884 kernel/sched/core.c:6695
[<ffffffff8360ca1c>] schedule+0x78/0xfe kernel/sched/core.c:6771
[<ffffffff83617bb6>] do_nanosleep+0x18a/0x318 kernel/time/hrtimer.c:2047
==================================================================
BUG: KASAN: out-of-bounds in walk_stackframe+0x130/0x2f2 arch/riscv/kernel/stacktrace.c:59
Read of size 8 at addr ff20000006d37c38 by task swapper/1/0

CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.6.0-rc1-syzkaller-g8eb8fe67e2c8 #0
Hardware name: riscv-virtio,qemu (DT)
Call Trace:
[<ffffffff8000b966>] dump_backtrace+0x2e/0x3c arch/riscv/kernel/stacktrace.c:121
[<ffffffff835c3860>] show_stack+0x34/0x40 arch/riscv/kernel/stacktrace.c:127
[<ffffffff836036ae>] __dump_stack lib/dump_stack.c:88 [inline]
[<ffffffff836036ae>] dump_stack_lvl+0xe8/0x154 lib/dump_stack.c:106
[<ffffffff835cbf28>] print_address_description mm/kasan/report.c:364 [inline]
[<ffffffff835cbf28>] print_report+0x1e4/0x4f4 mm/kasan/report.c:475
[<ffffffff8057aa66>] kasan_report+0xf0/0x1ba mm/kasan/report.c:588
[<ffffffff8057bd82>] check_region_inline mm/kasan/generic.c:181 [inline]
[<ffffffff8057bd82>] __asan_load8+0x80/0xa8 mm/kasan/generic.c:260
[<ffffffff8000b712>] walk_stackframe+0x130/0x2f2 arch/riscv/kernel/stacktrace.c:59
[<ffffffff8000b966>] dump_backtrace+0x2e/0x3c arch/riscv/kernel/stacktrace.c:121
[<ffffffff835c3860>] show_stack+0x34/0x40 arch/riscv/kernel/stacktrace.c:127
[<ffffffff800f624a>] sched_show_task kernel/sched/core.c:9182 [inline]
[<ffffffff800f624a>] sched_show_task+0x2ee/0x414 kernel/sched/core.c:9156
[<ffffffff80100e02>] show_state_filter+0xa0/0x1e0 kernel/sched/core.c:9227
[<ffffffff80fa0c7e>] show_state include/linux/sched/debug.h:21 [inline]
[<ffffffff80fa0c7e>] fn_show_state+0x1a/0x22 drivers/tty/vt/keyboard.c:614
[<ffffffff80fa1152>] k_spec drivers/tty/vt/keyboard.c:667 [inline]
[<ffffffff80fa1152>] k_spec+0xce/0x102 drivers/tty/vt/keyboard.c:656
[<ffffffff80fa306c>] kbd_keycode drivers/tty/vt/keyboard.c:1524 [inline]
[<ffffffff80fa306c>] kbd_event+0x5fa/0xa5e drivers/tty/vt/keyboard.c:1543
[<ffffffff821384ba>] input_to_handler+0x246/0x24c drivers/input/input.c:132
[<ffffffff8213d310>] input_pass_values+0x410/0x5fe drivers/input/input.c:161
[<ffffffff8213d6ec>] input_event_dispose+0x1ee/0x2c8 drivers/input/input.c:378
[<ffffffff8213f558>] input_handle_event+0xf0/0x972 drivers/input/input.c:406
[<ffffffff8213fe64>] input_event drivers/input/input.c:435 [inline]
[<ffffffff8213fe64>] input_event+0x8a/0xb2 drivers/input/input.c:427
[<ffffffff82678820>] input_sync include/linux/input.h:450 [inline]
[<ffffffff82678820>] hidinput_report_event+0x86/0xae drivers/hid/hid-input.c:1746
[<ffffffff8267261c>] hid_report_raw_event+0x1be/0xa5c drivers/hid/hid-core.c:2016
[<ffffffff82673108>] hid_input_report+0x24e/0x2f4 drivers/hid/hid-core.c:2083
[<ffffffff82738584>] hid_irq_in+0x244/0x412 drivers/hid/usbhid/hid-core.c:284
[<ffffffff81d6a49a>] __usb_hcd_giveback_urb+0x222/0x364 drivers/usb/core/hcd.c:1650
[<ffffffff81d6a856>] usb_hcd_giveback_urb+0x27a/0x290 drivers/usb/core/hcd.c:1733
[<ffffffff82027b14>] dummy_timer+0xfc2/0x204a drivers/usb/gadget/udc/dummy_hcd.c:1987
[<ffffffff801d42d2>] call_timer_fn+0x15a/0x4f2 kernel/time/timer.c:1700
[<ffffffff801d4be8>] expire_timers kernel/time/timer.c:1751 [inline]
[<ffffffff801d4be8>] __run_timers+0x57e/0x73c kernel/time/timer.c:2022
[<ffffffff801d4dec>] run_timer_softirq+0x46/0x80 kernel/time/timer.c:2035
[<ffffffff83619632>] __do_softirq+0x2ee/0x8a2 kernel/softirq.c:553
[<ffffffff8008af50>] invoke_softirq kernel/softirq.c:427 [inline]
[<ffffffff8008af50>] __irq_exit_rcu+0xfa/0x1b0 kernel/softirq.c:632
[<ffffffff8008b1e6>] irq_exit_rcu+0x10/0x72 kernel/softirq.c:644
[<ffffffff836044fa>] handle_riscv_irq+0x40/0x4c arch/riscv/kernel/traps.c:349
[<ffffffff83604bae>] do_irq+0x5c/0x86 arch/riscv/kernel/traps.c:359

The buggy address belongs to the virtual mapping at
 [ff20000006d30000, ff20000006d39000) created by:
 kernel_clone+0x118/0x896 kernel/fork.c:2909

The buggy address belongs to the physical page:
page:ff1c00000250dbc0 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x9436f
flags: 0xffe000000000000(node=0|zone=0|lastcpupid=0x7ff)
page_type: 0xffffffff()
raw: 0ffe000000000000 0000000000000000 0000000000000122 0000000000000000
raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0x2dc2(GFP_KERNEL|__GFP_HIGHMEM|__GFP_NOWARN|__GFP_ZERO), pid 32, tgid 32 (kworker/u6:1), ts 67487133600, free_ts 66877452400
 __set_page_owner+0x32/0x18a mm/page_owner.c:192
 set_page_owner include/linux/page_owner.h:31 [inline]
 post_alloc_hook+0x8c/0xe2 mm/page_alloc.c:1536
 prep_new_page mm/page_alloc.c:1543 [inline]
 get_page_from_freelist+0x84a/0x121e mm/page_alloc.c:3170
 __alloc_pages+0x19c/0x142e mm/page_alloc.c:4426
 alloc_pages+0x126/0x252 mm/mempolicy.c:2298
 vm_area_alloc_pages mm/vmalloc.c:3063 [inline]
 __vmalloc_area_node mm/vmalloc.c:3139 [inline]
 __vmalloc_node_range+0x838/0xec2 mm/vmalloc.c:3320
 alloc_thread_stack_node kernel/fork.c:309 [inline]
 dup_task_struct kernel/fork.c:1118 [inline]
 copy_process+0x225a/0x3f1e kernel/fork.c:2327
 kernel_clone+0x118/0x896 kernel/fork.c:2909
 user_mode_thread+0xea/0x11a kernel/fork.c:2987
 call_usermodehelper_exec_work kernel/umh.c:172 [inline]
 call_usermodehelper_exec_work+0xc8/0x122 kernel/umh.c:158
 process_one_work+0x54c/0xd66 kernel/workqueue.c:2630
 process_scheduled_works kernel/workqueue.c:2703 [inline]
 worker_thread+0x506/0x980 kernel/workqueue.c:2784
 kthread+0x1bc/0x22c kernel/kthread.c:388
 ret_from_fork+0xa/0x1c arch/riscv/kernel/entry.S:264
page last free stack trace:
 __reset_page_owner+0x4c/0xf8 mm/page_owner.c:149
 reset_page_owner include/linux/page_owner.h:24 [inline]
 free_pages_prepare mm/page_alloc.c:1136 [inline]
 free_unref_page_prepare+0x224/0x592 mm/page_alloc.c:2312
 free_unref_page+0x5a/0x234 mm/page_alloc.c:2405
 free_the_page mm/page_alloc.c:562 [inline]
 __free_pages+0x104/0x126 mm/page_alloc.c:4516
 vfree+0x14c/0x68e mm/vmalloc.c:2842
 delayed_vfree_work+0x42/0x58 mm/vmalloc.c:2763
 process_one_work+0x54c/0xd66 kernel/workqueue.c:2630
 process_scheduled_works kernel/workqueue.c:2703 [inline]
 worker_thread+0x506/0x980 kernel/workqueue.c:2784
 kthread+0x1bc/0x22c kernel/kthread.c:388
 ret_from_fork+0xa/0x1c arch/riscv/kernel/entry.S:264

Memory state around the buggy address:
 ff20000006d37b00: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
 ff20000006d37b80: 00 00 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
>ff20000006d37c00: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
                                           ^
 ff20000006d37c80: f1 f1 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3
 ff20000006d37d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================


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

[PATCH] riscv: fix out of bounds in walk_stackframe

[Edward AD]

Increase the check on the frame after assigning its value. This is to prevent 
frame access from crossing boundaries.

Reported-and-tested-by: syzbot+8d2757d62d403b2d9275@syzkaller.appspotmail.com
Signed-off-by: Edward AD <twuufnxlz@gmail.com>
---
 arch/riscv/kernel/stacktrace.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/riscv/kernel/stacktrace.c b/arch/riscv/kernel/stacktrace.c
index 64a9c093aef9..53bd18672329 100644
--- a/arch/riscv/kernel/stacktrace.c
+++ b/arch/riscv/kernel/stacktrace.c
@@ -54,6 +54,8 @@ void notrace walk_stackframe(struct task_struct *task, struct pt_regs *regs,
 			break;
 		/* Unwind stack frame */
 		frame = (struct stackframe *)fp - 1;
+		if (!virt_addr_valid(frame))
+			break;
 		sp = fp;
 		if (regs && (regs->epc == pc) && (frame->fp & 0x7)) {
 			fp = frame->ra;
-- 
2.25.1

Re: [PATCH] riscv: fix out of bounds in walk_stackframe

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 1277 bytes --]

Hey Edward,

Where did you come up with the CC list for this patch from? Please run
get_maintainer.pl on your patches and CC the output. You've not CCed any
relevant developers on this mail :(

On Tue, Sep 26, 2023 at 06:59:50PM +0800, Edward AD wrote:
> Increase the check on the frame after assigning its value. This is to prevent 
> frame access from crossing boundaries.
> 
> Reported-and-tested-by: syzbot+8d2757d62d403b2d9275@syzkaller.appspotmail.com

Please also add a Fixes: tag & a Closes: tag with a link to the report
when you do so.

Thanks,
Conor.

> Signed-off-by: Edward AD <twuufnxlz@gmail.com>
> ---
>  arch/riscv/kernel/stacktrace.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/riscv/kernel/stacktrace.c b/arch/riscv/kernel/stacktrace.c
> index 64a9c093aef9..53bd18672329 100644
> --- a/arch/riscv/kernel/stacktrace.c
> +++ b/arch/riscv/kernel/stacktrace.c
> @@ -54,6 +54,8 @@ void notrace walk_stackframe(struct task_struct *task, struct pt_regs *regs,
>  			break;
>  		/* Unwind stack frame */
>  		frame = (struct stackframe *)fp - 1;
> +		if (!virt_addr_valid(frame))
> +			break;
>  		sp = fp;
>  		if (regs && (regs->epc == pc) && (frame->fp & 0x7)) {
>  			fp = frame->ra;
> -- 
> 2.25.1
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[PATCH] riscv: fix out of bounds in walk_stackframe

[Edward AD]

Increase the check on the frame after assigning its value. This is to prevent 
frame access from crossing boundaries.

Closes: https://lore.kernel.org/all/20230926105949.1025995-2-twuufnxlz@gmail.com/
Fixes: 5d8544e2d007 ("RISC-V: Generic library routines and assembly")
Reported-and-tested-by: syzbot+8d2757d62d403b2d9275@syzkaller.appspotmail.com
Link: https://lore.kernel.org/all/0000000000000170df0605ccf91a@google.com/T/
Signed-off-by: Edward AD <twuufnxlz@gmail.com>
---
 arch/riscv/kernel/stacktrace.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/riscv/kernel/stacktrace.c b/arch/riscv/kernel/stacktrace.c
index 64a9c093aef9..53bd18672329 100644
--- a/arch/riscv/kernel/stacktrace.c
+++ b/arch/riscv/kernel/stacktrace.c
@@ -54,6 +54,8 @@ void notrace walk_stackframe(struct task_struct *task, struct pt_regs *regs,
 			break;
 		/* Unwind stack frame */
 		frame = (struct stackframe *)fp - 1;
+		if (!virt_addr_valid(frame))
+			break;
 		sp = fp;
 		if (regs && (regs->epc == pc) && (frame->fp & 0x7)) {
 			fp = frame->ra;
-- 
2.25.1


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH] riscv: fix out of bounds in walk_stackframe

[Edward AD]

Increase the check on the frame after assigning its value. This is to prevent 
frame access from crossing boundaries.

Closes: https://lore.kernel.org/all/20230926105949.1025995-2-twuufnxlz@gmail.com/
Fixes: 5d8544e2d007 ("RISC-V: Generic library routines and assembly")
Reported-and-tested-by: syzbot+8d2757d62d403b2d9275@syzkaller.appspotmail.com
Link: https://lore.kernel.org/all/0000000000000170df0605ccf91a@google.com/T/
Signed-off-by: Edward AD <twuufnxlz@gmail.com>
---
 arch/riscv/kernel/stacktrace.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/riscv/kernel/stacktrace.c b/arch/riscv/kernel/stacktrace.c
index 64a9c093aef9..53bd18672329 100644
--- a/arch/riscv/kernel/stacktrace.c
+++ b/arch/riscv/kernel/stacktrace.c
@@ -54,6 +54,8 @@ void notrace walk_stackframe(struct task_struct *task, struct pt_regs *regs,
 			break;
 		/* Unwind stack frame */
 		frame = (struct stackframe *)fp - 1;
+		if (!virt_addr_valid(frame))
+			break;
 		sp = fp;
 		if (regs && (regs->epc == pc) && (frame->fp & 0x7)) {
 			fp = frame->ra;
-- 
2.25.1

Re: [PATCH] riscv: fix out of bounds in walk_stackframe

[Greg KH]

On Tue, Sep 26, 2023 at 07:43:44PM +0800, Edward AD wrote:
> Increase the check on the frame after assigning its value. This is to prevent 
> frame access from crossing boundaries.
> 
> Closes: https://lore.kernel.org/all/20230926105949.1025995-2-twuufnxlz@gmail.com/
> Fixes: 5d8544e2d007 ("RISC-V: Generic library routines and assembly")
> Reported-and-tested-by: syzbot+8d2757d62d403b2d9275@syzkaller.appspotmail.com
> Link: https://lore.kernel.org/all/0000000000000170df0605ccf91a@google.com/T/
> Signed-off-by: Edward AD <twuufnxlz@gmail.com>
> ---
>  arch/riscv/kernel/stacktrace.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/riscv/kernel/stacktrace.c b/arch/riscv/kernel/stacktrace.c
> index 64a9c093aef9..53bd18672329 100644
> --- a/arch/riscv/kernel/stacktrace.c
> +++ b/arch/riscv/kernel/stacktrace.c
> @@ -54,6 +54,8 @@ void notrace walk_stackframe(struct task_struct *task, struct pt_regs *regs,
>  			break;
>  		/* Unwind stack frame */
>  		frame = (struct stackframe *)fp - 1;
> +		if (!virt_addr_valid(frame))
> +			break;
>  		sp = fp;
>  		if (regs && (regs->epc == pc) && (frame->fp & 0x7)) {
>  			fp = frame->ra;
> -- 
> 2.25.1
> 

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- You have marked a patch with a "Fixes:" tag for a commit that is in an
  older released kernel, yet you do not have a cc: stable line in the
  signed-off-by area at all, which means that the patch will not be
  applied to any older kernel releases.  To properly fix this, please
  follow the documented rules in the
  Documetnation/process/stable-kernel-rules.rst file for how to resolve
  this.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH] riscv: fix out of bounds in walk_stackframe

[Greg KH]

On Tue, Sep 26, 2023 at 07:43:44PM +0800, Edward AD wrote:
> Increase the check on the frame after assigning its value. This is to prevent 
> frame access from crossing boundaries.
> 
> Closes: https://lore.kernel.org/all/20230926105949.1025995-2-twuufnxlz@gmail.com/
> Fixes: 5d8544e2d007 ("RISC-V: Generic library routines and assembly")
> Reported-and-tested-by: syzbot+8d2757d62d403b2d9275@syzkaller.appspotmail.com
> Link: https://lore.kernel.org/all/0000000000000170df0605ccf91a@google.com/T/
> Signed-off-by: Edward AD <twuufnxlz@gmail.com>
> ---
>  arch/riscv/kernel/stacktrace.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/riscv/kernel/stacktrace.c b/arch/riscv/kernel/stacktrace.c
> index 64a9c093aef9..53bd18672329 100644
> --- a/arch/riscv/kernel/stacktrace.c
> +++ b/arch/riscv/kernel/stacktrace.c
> @@ -54,6 +54,8 @@ void notrace walk_stackframe(struct task_struct *task, struct pt_regs *regs,
>  			break;
>  		/* Unwind stack frame */
>  		frame = (struct stackframe *)fp - 1;
> +		if (!virt_addr_valid(frame))
> +			break;
>  		sp = fp;
>  		if (regs && (regs->epc == pc) && (frame->fp & 0x7)) {
>  			fp = frame->ra;
> -- 
> 2.25.1
> 

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- You have marked a patch with a "Fixes:" tag for a commit that is in an
  older released kernel, yet you do not have a cc: stable line in the
  signed-off-by area at all, which means that the patch will not be
  applied to any older kernel releases.  To properly fix this, please
  follow the documented rules in the
  Documetnation/process/stable-kernel-rules.rst file for how to resolve
  this.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot

Re: [PATCH] riscv: fix out of bounds in walk_stackframe

[Alexandre Ghiti]

Hi Edward,

On 26/09/2023 13:43, Edward AD wrote:
> Increase the check on the frame after assigning its value. This is to prevent
> frame access from crossing boundaries.
>
> Closes: https://lore.kernel.org/all/20230926105949.1025995-2-twuufnxlz@gmail.com/
> Fixes: 5d8544e2d007 ("RISC-V: Generic library routines and assembly")
> Reported-and-tested-by: syzbot+8d2757d62d403b2d9275@syzkaller.appspotmail.com
> Link: https://lore.kernel.org/all/0000000000000170df0605ccf91a@google.com/T/
> Signed-off-by: Edward AD <twuufnxlz@gmail.com>
> ---
>   arch/riscv/kernel/stacktrace.c | 2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/arch/riscv/kernel/stacktrace.c b/arch/riscv/kernel/stacktrace.c
> index 64a9c093aef9..53bd18672329 100644
> --- a/arch/riscv/kernel/stacktrace.c
> +++ b/arch/riscv/kernel/stacktrace.c
> @@ -54,6 +54,8 @@ void notrace walk_stackframe(struct task_struct *task, struct pt_regs *regs,
>   			break;
>   		/* Unwind stack frame */
>   		frame = (struct stackframe *)fp - 1;
> +		if (!virt_addr_valid(frame))
> +			break;
>   		sp = fp;
>   		if (regs && (regs->epc == pc) && (frame->fp & 0x7)) {
>   			fp = frame->ra;


virt_addr_valid() works on kernel linear addresses, not on vmalloc 
addresses, which is the case here  (0xff20000006d37c38 belongs to the 
vmalloc region: see 
https://elixir.bootlin.com/linux/latest/source/Documentation/riscv/vm-layout.rst#L125). 
So this fix can't work.

I'm a bit surprised though of this out-of-bounds access since 
CONFIG_FRAME_POINTER is enabled, so there may be a real issue here (the 
console output is horrible, lots of backtraces, which is weird), so it 
may be worth digging into that.

Thanks,

Alex



_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH] riscv: fix out of bounds in walk_stackframe

[Alexandre Ghiti]

Hi Edward,

On 26/09/2023 13:43, Edward AD wrote:
> Increase the check on the frame after assigning its value. This is to prevent
> frame access from crossing boundaries.
>
> Closes: https://lore.kernel.org/all/20230926105949.1025995-2-twuufnxlz@gmail.com/
> Fixes: 5d8544e2d007 ("RISC-V: Generic library routines and assembly")
> Reported-and-tested-by: syzbot+8d2757d62d403b2d9275@syzkaller.appspotmail.com
> Link: https://lore.kernel.org/all/0000000000000170df0605ccf91a@google.com/T/
> Signed-off-by: Edward AD <twuufnxlz@gmail.com>
> ---
>   arch/riscv/kernel/stacktrace.c | 2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/arch/riscv/kernel/stacktrace.c b/arch/riscv/kernel/stacktrace.c
> index 64a9c093aef9..53bd18672329 100644
> --- a/arch/riscv/kernel/stacktrace.c
> +++ b/arch/riscv/kernel/stacktrace.c
> @@ -54,6 +54,8 @@ void notrace walk_stackframe(struct task_struct *task, struct pt_regs *regs,
>   			break;
>   		/* Unwind stack frame */
>   		frame = (struct stackframe *)fp - 1;
> +		if (!virt_addr_valid(frame))
> +			break;
>   		sp = fp;
>   		if (regs && (regs->epc == pc) && (frame->fp & 0x7)) {
>   			fp = frame->ra;


virt_addr_valid() works on kernel linear addresses, not on vmalloc 
addresses, which is the case here  (0xff20000006d37c38 belongs to the 
vmalloc region: see 
https://elixir.bootlin.com/linux/latest/source/Documentation/riscv/vm-layout.rst#L125). 
So this fix can't work.

I'm a bit surprised though of this out-of-bounds access since 
CONFIG_FRAME_POINTER is enabled, so there may be a real issue here (the 
console output is horrible, lots of backtraces, which is weird), so it 
may be worth digging into that.

Thanks,

Alex

Re: [PATCH] riscv: fix out of bounds in walk_stackframe

[Alexandre Ghiti]

Oh and BTW, any idea why linux-riscv was not in CC for the initial report?

On 28/09/2023 10:02, Alexandre Ghiti wrote:
> Hi Edward,
>
> On 26/09/2023 13:43, Edward AD wrote:
>> Increase the check on the frame after assigning its value. This is to 
>> prevent
>> frame access from crossing boundaries.
>>
>> Closes: 
>> https://lore.kernel.org/all/20230926105949.1025995-2-twuufnxlz@gmail.com/
>> Fixes: 5d8544e2d007 ("RISC-V: Generic library routines and assembly")
>> Reported-and-tested-by: 
>> syzbot+8d2757d62d403b2d9275@syzkaller.appspotmail.com
>> Link: 
>> https://lore.kernel.org/all/0000000000000170df0605ccf91a@google.com/T/
>> Signed-off-by: Edward AD <twuufnxlz@gmail.com>
>> ---
>>   arch/riscv/kernel/stacktrace.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/riscv/kernel/stacktrace.c 
>> b/arch/riscv/kernel/stacktrace.c
>> index 64a9c093aef9..53bd18672329 100644
>> --- a/arch/riscv/kernel/stacktrace.c
>> +++ b/arch/riscv/kernel/stacktrace.c
>> @@ -54,6 +54,8 @@ void notrace walk_stackframe(struct task_struct 
>> *task, struct pt_regs *regs,
>>               break;
>>           /* Unwind stack frame */
>>           frame = (struct stackframe *)fp - 1;
>> +        if (!virt_addr_valid(frame))
>> +            break;
>>           sp = fp;
>>           if (regs && (regs->epc == pc) && (frame->fp & 0x7)) {
>>               fp = frame->ra;
>
>
> virt_addr_valid() works on kernel linear addresses, not on vmalloc 
> addresses, which is the case here  (0xff20000006d37c38 belongs to the 
> vmalloc region: see 
> https://elixir.bootlin.com/linux/latest/source/Documentation/riscv/vm-layout.rst#L125). 
> So this fix can't work.
>
> I'm a bit surprised though of this out-of-bounds access since 
> CONFIG_FRAME_POINTER is enabled, so there may be a real issue here 
> (the console output is horrible, lots of backtraces, which is weird), 
> so it may be worth digging into that.
>
> Thanks,
>
> Alex
>
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH] riscv: fix out of bounds in walk_stackframe

[Alexandre Ghiti]

Oh and BTW, any idea why linux-riscv was not in CC for the initial report?

On 28/09/2023 10:02, Alexandre Ghiti wrote:
> Hi Edward,
>
> On 26/09/2023 13:43, Edward AD wrote:
>> Increase the check on the frame after assigning its value. This is to 
>> prevent
>> frame access from crossing boundaries.
>>
>> Closes: 
>> https://lore.kernel.org/all/20230926105949.1025995-2-twuufnxlz@gmail.com/
>> Fixes: 5d8544e2d007 ("RISC-V: Generic library routines and assembly")
>> Reported-and-tested-by: 
>> syzbot+8d2757d62d403b2d9275@syzkaller.appspotmail.com
>> Link: 
>> https://lore.kernel.org/all/0000000000000170df0605ccf91a@google.com/T/
>> Signed-off-by: Edward AD <twuufnxlz@gmail.com>
>> ---
>>   arch/riscv/kernel/stacktrace.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/riscv/kernel/stacktrace.c 
>> b/arch/riscv/kernel/stacktrace.c
>> index 64a9c093aef9..53bd18672329 100644
>> --- a/arch/riscv/kernel/stacktrace.c
>> +++ b/arch/riscv/kernel/stacktrace.c
>> @@ -54,6 +54,8 @@ void notrace walk_stackframe(struct task_struct 
>> *task, struct pt_regs *regs,
>>               break;
>>           /* Unwind stack frame */
>>           frame = (struct stackframe *)fp - 1;
>> +        if (!virt_addr_valid(frame))
>> +            break;
>>           sp = fp;
>>           if (regs && (regs->epc == pc) && (frame->fp & 0x7)) {
>>               fp = frame->ra;
>
>
> virt_addr_valid() works on kernel linear addresses, not on vmalloc 
> addresses, which is the case here  (0xff20000006d37c38 belongs to the 
> vmalloc region: see 
> https://elixir.bootlin.com/linux/latest/source/Documentation/riscv/vm-layout.rst#L125). 
> So this fix can't work.
>
> I'm a bit surprised though of this out-of-bounds access since 
> CONFIG_FRAME_POINTER is enabled, so there may be a real issue here 
> (the console output is horrible, lots of backtraces, which is weird), 
> so it may be worth digging into that.
>
> Thanks,
>
> Alex
>
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH] riscv: fix out of bounds in walk_stackframe

[Edward AD]

Add vmalloc and kernel addresses check to prevent invalid access.

Closes: https://lore.kernel.org/all/20230926105949.1025995-2-twuufnxlz@gmail.com/
Fixes: 5d8544e2d007 ("RISC-V: Generic library routines and assembly")
Reported-and-test-by: syzbot+8d2757d62d403b2d9275@syzkaller.appspotmail.com
Link: https://lore.kernel.org/all/0000000000000170df0605ccf91a@google.com/T/
Signed-off-by: Edward AD <twuufnxlz@gmail.com>
---
 arch/riscv/kernel/stacktrace.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/riscv/kernel/stacktrace.c b/arch/riscv/kernel/stacktrace.c
index 64a9c093aef9..031a4a35c1d0 100644
--- a/arch/riscv/kernel/stacktrace.c
+++ b/arch/riscv/kernel/stacktrace.c
@@ -54,6 +54,9 @@ void notrace walk_stackframe(struct task_struct *task, struct pt_regs *regs,
 			break;
 		/* Unwind stack frame */
 		frame = (struct stackframe *)fp - 1;
+		if ((is_vmalloc_addr(frame) && !pfn_valid(page_to_pfn(vmalloc_to_page(frame)))) || 
+		     !virt_addr_valid(frame))
+			break;
 		sp = fp;
 		if (regs && (regs->epc == pc) && (frame->fp & 0x7)) {
 			fp = frame->ra;
-- 
2.25.1


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH] riscv: fix out of bounds in walk_stackframe

[Edward AD]

Add vmalloc and kernel addresses check to prevent invalid access.

Closes: https://lore.kernel.org/all/20230926105949.1025995-2-twuufnxlz@gmail.com/
Fixes: 5d8544e2d007 ("RISC-V: Generic library routines and assembly")
Reported-and-test-by: syzbot+8d2757d62d403b2d9275@syzkaller.appspotmail.com
Link: https://lore.kernel.org/all/0000000000000170df0605ccf91a@google.com/T/
Signed-off-by: Edward AD <twuufnxlz@gmail.com>
---
 arch/riscv/kernel/stacktrace.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/riscv/kernel/stacktrace.c b/arch/riscv/kernel/stacktrace.c
index 64a9c093aef9..031a4a35c1d0 100644
--- a/arch/riscv/kernel/stacktrace.c
+++ b/arch/riscv/kernel/stacktrace.c
@@ -54,6 +54,9 @@ void notrace walk_stackframe(struct task_struct *task, struct pt_regs *regs,
 			break;
 		/* Unwind stack frame */
 		frame = (struct stackframe *)fp - 1;
+		if ((is_vmalloc_addr(frame) && !pfn_valid(page_to_pfn(vmalloc_to_page(frame)))) || 
+		     !virt_addr_valid(frame))
+			break;
 		sp = fp;
 		if (regs && (regs->epc == pc) && (frame->fp & 0x7)) {
 			fp = frame->ra;
-- 
2.25.1

Re: [PATCH] riscv: fix out of bounds in walk_stackframe

[Greg KH]

On Fri, Sep 29, 2023 at 07:12:40AM +0800, Edward AD wrote:
> Add vmalloc and kernel addresses check to prevent invalid access.
> 
> Closes: https://lore.kernel.org/all/20230926105949.1025995-2-twuufnxlz@gmail.com/
> Fixes: 5d8544e2d007 ("RISC-V: Generic library routines and assembly")
> Reported-and-test-by: syzbot+8d2757d62d403b2d9275@syzkaller.appspotmail.com
> Link: https://lore.kernel.org/all/0000000000000170df0605ccf91a@google.com/T/
> Signed-off-by: Edward AD <twuufnxlz@gmail.com>
> ---
>  arch/riscv/kernel/stacktrace.c | 3 +++

Where are you getting your odd cc: list from?  This has nothing to do
with serial drivers...

greg k-h

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH] riscv: fix out of bounds in walk_stackframe

[Greg KH]

On Fri, Sep 29, 2023 at 07:12:40AM +0800, Edward AD wrote:
> Add vmalloc and kernel addresses check to prevent invalid access.
> 
> Closes: https://lore.kernel.org/all/20230926105949.1025995-2-twuufnxlz@gmail.com/
> Fixes: 5d8544e2d007 ("RISC-V: Generic library routines and assembly")
> Reported-and-test-by: syzbot+8d2757d62d403b2d9275@syzkaller.appspotmail.com
> Link: https://lore.kernel.org/all/0000000000000170df0605ccf91a@google.com/T/
> Signed-off-by: Edward AD <twuufnxlz@gmail.com>
> ---
>  arch/riscv/kernel/stacktrace.c | 3 +++

Where are you getting your odd cc: list from?  This has nothing to do
with serial drivers...

greg k-h

Re: [PATCH] riscv: fix out of bounds in walk_stackframe

[Greg KH]

On Fri, Sep 29, 2023 at 07:12:40AM +0800, Edward AD wrote:
> Add vmalloc and kernel addresses check to prevent invalid access.
> 
> Closes: https://lore.kernel.org/all/20230926105949.1025995-2-twuufnxlz@gmail.com/
> Fixes: 5d8544e2d007 ("RISC-V: Generic library routines and assembly")
> Reported-and-test-by: syzbot+8d2757d62d403b2d9275@syzkaller.appspotmail.com
> Link: https://lore.kernel.org/all/0000000000000170df0605ccf91a@google.com/T/
> Signed-off-by: Edward AD <twuufnxlz@gmail.com>
> ---
>  arch/riscv/kernel/stacktrace.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/riscv/kernel/stacktrace.c b/arch/riscv/kernel/stacktrace.c
> index 64a9c093aef9..031a4a35c1d0 100644
> --- a/arch/riscv/kernel/stacktrace.c
> +++ b/arch/riscv/kernel/stacktrace.c
> @@ -54,6 +54,9 @@ void notrace walk_stackframe(struct task_struct *task, struct pt_regs *regs,
>  			break;
>  		/* Unwind stack frame */
>  		frame = (struct stackframe *)fp - 1;
> +		if ((is_vmalloc_addr(frame) && !pfn_valid(page_to_pfn(vmalloc_to_page(frame)))) || 
> +		     !virt_addr_valid(frame))
> +			break;
>  		sp = fp;
>  		if (regs && (regs->epc == pc) && (frame->fp & 0x7)) {
>  			fp = frame->ra;
> -- 
> 2.25.1
> 

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- Your patch contains warnings and/or errors noticed by the
  scripts/checkpatch.pl tool.

- You have marked a patch with a "Fixes:" tag for a commit that is in an
  older released kernel, yet you do not have a cc: stable line in the
  signed-off-by area at all, which means that the patch will not be
  applied to any older kernel releases.  To properly fix this, please
  follow the documented rules in the
  Documetnation/process/stable-kernel-rules.rst file for how to resolve
  this.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH] riscv: fix out of bounds in walk_stackframe

[Greg KH]

On Fri, Sep 29, 2023 at 07:12:40AM +0800, Edward AD wrote:
> Add vmalloc and kernel addresses check to prevent invalid access.
> 
> Closes: https://lore.kernel.org/all/20230926105949.1025995-2-twuufnxlz@gmail.com/
> Fixes: 5d8544e2d007 ("RISC-V: Generic library routines and assembly")
> Reported-and-test-by: syzbot+8d2757d62d403b2d9275@syzkaller.appspotmail.com
> Link: https://lore.kernel.org/all/0000000000000170df0605ccf91a@google.com/T/
> Signed-off-by: Edward AD <twuufnxlz@gmail.com>
> ---
>  arch/riscv/kernel/stacktrace.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/riscv/kernel/stacktrace.c b/arch/riscv/kernel/stacktrace.c
> index 64a9c093aef9..031a4a35c1d0 100644
> --- a/arch/riscv/kernel/stacktrace.c
> +++ b/arch/riscv/kernel/stacktrace.c
> @@ -54,6 +54,9 @@ void notrace walk_stackframe(struct task_struct *task, struct pt_regs *regs,
>  			break;
>  		/* Unwind stack frame */
>  		frame = (struct stackframe *)fp - 1;
> +		if ((is_vmalloc_addr(frame) && !pfn_valid(page_to_pfn(vmalloc_to_page(frame)))) || 
> +		     !virt_addr_valid(frame))
> +			break;
>  		sp = fp;
>  		if (regs && (regs->epc == pc) && (frame->fp & 0x7)) {
>  			fp = frame->ra;
> -- 
> 2.25.1
> 

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- Your patch contains warnings and/or errors noticed by the
  scripts/checkpatch.pl tool.

- You have marked a patch with a "Fixes:" tag for a commit that is in an
  older released kernel, yet you do not have a cc: stable line in the
  signed-off-by area at all, which means that the patch will not be
  applied to any older kernel releases.  To properly fix this, please
  follow the documented rules in the
  Documetnation/process/stable-kernel-rules.rst file for how to resolve
  this.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot

Re: [PATCH] riscv: fix out of bounds in walk_stackframe

[Alexandre Ghiti]

Hi Edward,

On Fri, Sep 29, 2023 at 1:12 AM Edward AD <twuufnxlz@gmail.com> wrote:
>
> Add vmalloc and kernel addresses check to prevent invalid access.
>
> Closes: https://lore.kernel.org/all/20230926105949.1025995-2-twuufnxlz@gmail.com/
> Fixes: 5d8544e2d007 ("RISC-V: Generic library routines and assembly")
> Reported-and-test-by: syzbot+8d2757d62d403b2d9275@syzkaller.appspotmail.com
> Link: https://lore.kernel.org/all/0000000000000170df0605ccf91a@google.com/T/
> Signed-off-by: Edward AD <twuufnxlz@gmail.com>
> ---
>  arch/riscv/kernel/stacktrace.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/arch/riscv/kernel/stacktrace.c b/arch/riscv/kernel/stacktrace.c
> index 64a9c093aef9..031a4a35c1d0 100644
> --- a/arch/riscv/kernel/stacktrace.c
> +++ b/arch/riscv/kernel/stacktrace.c
> @@ -54,6 +54,9 @@ void notrace walk_stackframe(struct task_struct *task, struct pt_regs *regs,
>                         break;
>                 /* Unwind stack frame */
>                 frame = (struct stackframe *)fp - 1;
> +               if ((is_vmalloc_addr(frame) && !pfn_valid(page_to_pfn(vmalloc_to_page(frame)))) ||
> +                    !virt_addr_valid(frame))
> +                       break;
>                 sp = fp;
>                 if (regs && (regs->epc == pc) && (frame->fp & 0x7)) {
>                         fp = frame->ra;
> --
> 2.25.1
>

I'm still not convinced this will fix the kasan out-of-bounds
accesses, the page can be valid but the read can happen at an offset
not initialized and trigger such errors right? I still think there is
something weird about the stack frame, as to me this should not happen
(but admittedly I don't know much about that).

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH] riscv: fix out of bounds in walk_stackframe

[Alexandre Ghiti]

Hi Edward,

On Fri, Sep 29, 2023 at 1:12 AM Edward AD <twuufnxlz@gmail.com> wrote:
>
> Add vmalloc and kernel addresses check to prevent invalid access.
>
> Closes: https://lore.kernel.org/all/20230926105949.1025995-2-twuufnxlz@gmail.com/
> Fixes: 5d8544e2d007 ("RISC-V: Generic library routines and assembly")
> Reported-and-test-by: syzbot+8d2757d62d403b2d9275@syzkaller.appspotmail.com
> Link: https://lore.kernel.org/all/0000000000000170df0605ccf91a@google.com/T/
> Signed-off-by: Edward AD <twuufnxlz@gmail.com>
> ---
>  arch/riscv/kernel/stacktrace.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/arch/riscv/kernel/stacktrace.c b/arch/riscv/kernel/stacktrace.c
> index 64a9c093aef9..031a4a35c1d0 100644
> --- a/arch/riscv/kernel/stacktrace.c
> +++ b/arch/riscv/kernel/stacktrace.c
> @@ -54,6 +54,9 @@ void notrace walk_stackframe(struct task_struct *task, struct pt_regs *regs,
>                         break;
>                 /* Unwind stack frame */
>                 frame = (struct stackframe *)fp - 1;
> +               if ((is_vmalloc_addr(frame) && !pfn_valid(page_to_pfn(vmalloc_to_page(frame)))) ||
> +                    !virt_addr_valid(frame))
> +                       break;
>                 sp = fp;
>                 if (regs && (regs->epc == pc) && (frame->fp & 0x7)) {
>                         fp = frame->ra;
> --
> 2.25.1
>

I'm still not convinced this will fix the kasan out-of-bounds
accesses, the page can be valid but the read can happen at an offset
not initialized and trigger such errors right? I still think there is
something weird about the stack frame, as to me this should not happen
(but admittedly I don't know much about that).

[PATCH] Test for riscv fixes

[Edward AD]

On Fri, 29 Sep 2023 08:04:57 +0200 Greg KH wrote:
> Where are you getting your odd cc: list from?  This has nothing to do
> with serial drivers...
https://lore.kernel.org/all/0000000000000170df0605ccf91a@google.com/raw

Thanks,
edward

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH] Test for riscv fixes

[Edward AD]

On Fri, 29 Sep 2023 08:04:57 +0200 Greg KH wrote:
> Where are you getting your odd cc: list from?  This has nothing to do
> with serial drivers...
https://lore.kernel.org/all/0000000000000170df0605ccf91a@google.com/raw

Thanks,
edward

[PATCH] Test for riscv fixes

[Edward AD]

Hi Alexandre,

On Fri, 29 Sep 2023 10:25:59 +0200 Alexandre Ghiti <alexghiti@rivosinc.com> wrote:
> I'm still not convinced this will fix the kasan out-of-bounds
> accesses, the page can be valid but the read can happen at an offset
> not initialized and trigger such errors right? I still think there is
> something weird about the stack frame, as to me this should not happen
> (but admittedly I don't know much about that).
The added check can confirm that the physical page is invalid (whether it is a 
vmalloc allocated page or a slab allocated page), and exit the for loop when it is invalid.

Perhaps we can trust the test results of syzbot.

Thanks,
edward

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH] Test for riscv fixes

[Edward AD]

Hi Alexandre,

On Fri, 29 Sep 2023 10:25:59 +0200 Alexandre Ghiti <alexghiti@rivosinc.com> wrote:
> I'm still not convinced this will fix the kasan out-of-bounds
> accesses, the page can be valid but the read can happen at an offset
> not initialized and trigger such errors right? I still think there is
> something weird about the stack frame, as to me this should not happen
> (but admittedly I don't know much about that).
The added check can confirm that the physical page is invalid (whether it is a 
vmalloc allocated page or a slab allocated page), and exit the for loop when it is invalid.

Perhaps we can trust the test results of syzbot.

Thanks,
edward

Re: [PATCH] Test for riscv fixes

[Greg KH]

On Sat, Sep 30, 2023 at 07:05:35AM +0800, Edward AD wrote:
> On Fri, 29 Sep 2023 08:04:57 +0200 Greg KH wrote:
> > Where are you getting your odd cc: list from?  This has nothing to do
> > with serial drivers...
> https://lore.kernel.org/all/0000000000000170df0605ccf91a@google.com/raw

I do not understand this answer.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH] Test for riscv fixes

[Greg KH]

On Sat, Sep 30, 2023 at 07:05:35AM +0800, Edward AD wrote:
> On Fri, 29 Sep 2023 08:04:57 +0200 Greg KH wrote:
> > Where are you getting your odd cc: list from?  This has nothing to do
> > with serial drivers...
> https://lore.kernel.org/all/0000000000000170df0605ccf91a@google.com/raw

I do not understand this answer.

Re: [PATCH] Test for riscv fixes

[Conor Dooley]

[-- Attachment #1.1: Type: text/plain, Size: 538 bytes --]

On Sat, Sep 30, 2023 at 08:13:56AM +0200, Greg KH wrote:
> On Sat, Sep 30, 2023 at 07:05:35AM +0800, Edward AD wrote:
> > On Fri, 29 Sep 2023 08:04:57 +0200 Greg KH wrote:
> > > Where are you getting your odd cc: list from?  This has nothing to do
> > > with serial drivers...
> > https://lore.kernel.org/all/0000000000000170df0605ccf91a@google.com/raw
> 
> I do not understand this answer.

AIUI, the original report from syzbot "blamed" the serial maintainers.
Not too sure how it determined that though, given the contents.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH] Test for riscv fixes

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 538 bytes --]

On Sat, Sep 30, 2023 at 08:13:56AM +0200, Greg KH wrote:
> On Sat, Sep 30, 2023 at 07:05:35AM +0800, Edward AD wrote:
> > On Fri, 29 Sep 2023 08:04:57 +0200 Greg KH wrote:
> > > Where are you getting your odd cc: list from?  This has nothing to do
> > > with serial drivers...
> > https://lore.kernel.org/all/0000000000000170df0605ccf91a@google.com/raw
> 
> I do not understand this answer.

AIUI, the original report from syzbot "blamed" the serial maintainers.
Not too sure how it determined that though, given the contents.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH] Test for riscv fixes

[Alexandre Ghiti]

Hi Edward,

On Sat, Sep 30, 2023 at 1:06 AM Edward AD <twuufnxlz@gmail.com> wrote:
>
> Hi Alexandre,
>
> On Fri, 29 Sep 2023 10:25:59 +0200 Alexandre Ghiti <alexghiti@rivosinc.com> wrote:
> > I'm still not convinced this will fix the kasan out-of-bounds
> > accesses, the page can be valid but the read can happen at an offset
> > not initialized and trigger such errors right? I still think there is
> > something weird about the stack frame, as to me this should not happen
> > (but admittedly I don't know much about that).
> The added check can confirm that the physical page is invalid (whether it is a
> vmalloc allocated page or a slab allocated page), and exit the for loop when it is invalid.

Yes, but to me this is not what happens in the bug report you link:

| BUG: KASAN: out-of-bounds in walk_stackframe+0x130/0x2f2
arch/riscv/kernel/stacktrace.c:59
| Read of size 8 at addr ff20000006d37c38 by task swapper/1/0

So the read at address ff20000006d37c38 is not "normal" according to
KASAN (you can see there is no trap, meaning the physical mapping
exists).

| The buggy address belongs to the virtual mapping at
|  [ff20000006d30000, ff20000006d39000) created by:
| kernel_clone+0x118/0x896 kernel/fork.c:2909

The virtual address is legitimate since the vma exists ^

| The buggy address belongs to the physical page:
| page:ff1c00000250dbc0 refcount:1 mapcount:0 mapping:0000000000000000
index:0x0 pfn:0x9436f

And the physical page also exists ^

So I insist, checking that a physical mapping exists to exit the loop
is not enough, to me, the error here is that the backtrace goes "too
far" at an address where nothing was written before and then KASAN
complains about that, again, we don't take any page fault here so it's
not a problem of existing physical mapping.

>
> Perhaps we can trust the test results of syzbot.
>
> Thanks,
> edward

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH] Test for riscv fixes

[Alexandre Ghiti]

Hi Edward,

On Sat, Sep 30, 2023 at 1:06 AM Edward AD <twuufnxlz@gmail.com> wrote:
>
> Hi Alexandre,
>
> On Fri, 29 Sep 2023 10:25:59 +0200 Alexandre Ghiti <alexghiti@rivosinc.com> wrote:
> > I'm still not convinced this will fix the kasan out-of-bounds
> > accesses, the page can be valid but the read can happen at an offset
> > not initialized and trigger such errors right? I still think there is
> > something weird about the stack frame, as to me this should not happen
> > (but admittedly I don't know much about that).
> The added check can confirm that the physical page is invalid (whether it is a
> vmalloc allocated page or a slab allocated page), and exit the for loop when it is invalid.

Yes, but to me this is not what happens in the bug report you link:

| BUG: KASAN: out-of-bounds in walk_stackframe+0x130/0x2f2
arch/riscv/kernel/stacktrace.c:59
| Read of size 8 at addr ff20000006d37c38 by task swapper/1/0

So the read at address ff20000006d37c38 is not "normal" according to
KASAN (you can see there is no trap, meaning the physical mapping
exists).

| The buggy address belongs to the virtual mapping at
|  [ff20000006d30000, ff20000006d39000) created by:
| kernel_clone+0x118/0x896 kernel/fork.c:2909

The virtual address is legitimate since the vma exists ^

| The buggy address belongs to the physical page:
| page:ff1c00000250dbc0 refcount:1 mapcount:0 mapping:0000000000000000
index:0x0 pfn:0x9436f

And the physical page also exists ^

So I insist, checking that a physical mapping exists to exit the loop
is not enough, to me, the error here is that the backtrace goes "too
far" at an address where nothing was written before and then KASAN
complains about that, again, we don't take any page fault here so it's
not a problem of existing physical mapping.

>
> Perhaps we can trust the test results of syzbot.
>
> Thanks,
> edward

Re: [PATCH] Test for riscv fixes

[Aleksandr Nogikh]

On Sat, Sep 30, 2023 at 10:24 AM Conor Dooley <conor@kernel.org> wrote:
>
> On Sat, Sep 30, 2023 at 08:13:56AM +0200, Greg KH wrote:
> > On Sat, Sep 30, 2023 at 07:05:35AM +0800, Edward AD wrote:
> > > On Fri, 29 Sep 2023 08:04:57 +0200 Greg KH wrote:
> > > > Where are you getting your odd cc: list from?  This has nothing to do
> > > > with serial drivers...
> > > https://lore.kernel.org/all/0000000000000170df0605ccf91a@google.com/raw
> >
> > I do not understand this answer.
>
> AIUI, the original report from syzbot "blamed" the serial maintainers.
> Not too sure how it determined that though, given the contents.
>

blame is too strong a word for that auto-inferred hint :)

Yes, the actual problem was in a totally different place, but FWIW
here's how it happened:

Statistically, stacktrace.c and a number of other generic locations
are rather unlikely to actually contain the bug (they can, but the
chances are that it's deeper in the call stack), so syzbot, while
traversing the stack trace, skipped all frames until

[<ffffffff80fa0c7e>] fn_show_state+0x1a/0x22 drivers/tty/vt/keyboard.c:614
[<ffffffff80fa1152>] k_spec drivers/tty/vt/keyboard.c:667 [inline]
[<ffffffff80fa1152>] k_spec+0xce/0x102 drivers/tty/vt/keyboard.c:656
[<ffffffff80fa306c>] kbd_keycode drivers/tty/vt/keyboard.c:1524 [inline]
[<ffffffff80fa306c>] kbd_event+0x5fa/0xa5e drivers/tty/vt/keyboard.c:1543

Per MAINTAINERS, these locations belonged to "TTY LAYER AND SERIAL
DRIVERS". Therefore serial in Cc.

The automation actually attributes a lot of reports correctly, but,
unfortunately, there are also tricky cases like this.

-- 
Aleksandr

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH] Test for riscv fixes

[Aleksandr Nogikh]

On Sat, Sep 30, 2023 at 10:24 AM Conor Dooley <conor@kernel.org> wrote:
>
> On Sat, Sep 30, 2023 at 08:13:56AM +0200, Greg KH wrote:
> > On Sat, Sep 30, 2023 at 07:05:35AM +0800, Edward AD wrote:
> > > On Fri, 29 Sep 2023 08:04:57 +0200 Greg KH wrote:
> > > > Where are you getting your odd cc: list from?  This has nothing to do
> > > > with serial drivers...
> > > https://lore.kernel.org/all/0000000000000170df0605ccf91a@google.com/raw
> >
> > I do not understand this answer.
>
> AIUI, the original report from syzbot "blamed" the serial maintainers.
> Not too sure how it determined that though, given the contents.
>

blame is too strong a word for that auto-inferred hint :)

Yes, the actual problem was in a totally different place, but FWIW
here's how it happened:

Statistically, stacktrace.c and a number of other generic locations
are rather unlikely to actually contain the bug (they can, but the
chances are that it's deeper in the call stack), so syzbot, while
traversing the stack trace, skipped all frames until

[<ffffffff80fa0c7e>] fn_show_state+0x1a/0x22 drivers/tty/vt/keyboard.c:614
[<ffffffff80fa1152>] k_spec drivers/tty/vt/keyboard.c:667 [inline]
[<ffffffff80fa1152>] k_spec+0xce/0x102 drivers/tty/vt/keyboard.c:656
[<ffffffff80fa306c>] kbd_keycode drivers/tty/vt/keyboard.c:1524 [inline]
[<ffffffff80fa306c>] kbd_event+0x5fa/0xa5e drivers/tty/vt/keyboard.c:1543

Per MAINTAINERS, these locations belonged to "TTY LAYER AND SERIAL
DRIVERS". Therefore serial in Cc.

The automation actually attributes a lot of reports correctly, but,
unfortunately, there are also tricky cases like this.

-- 
Aleksandr

Re: [PATCH] Test for riscv fixes

[Mark Rutland]

On Mon, Oct 02, 2023 at 09:13:52AM +0200, Alexandre Ghiti wrote:
> Hi Edward,
> 
> On Sat, Sep 30, 2023 at 1:06 AM Edward AD <twuufnxlz@gmail.com> wrote:
> >
> > Hi Alexandre,
> >
> > On Fri, 29 Sep 2023 10:25:59 +0200 Alexandre Ghiti <alexghiti@rivosinc.com> wrote:
> > > I'm still not convinced this will fix the kasan out-of-bounds
> > > accesses, the page can be valid but the read can happen at an offset
> > > not initialized and trigger such errors right? I still think there is
> > > something weird about the stack frame, as to me this should not happen
> > > (but admittedly I don't know much about that).
> > The added check can confirm that the physical page is invalid (whether it is a
> > vmalloc allocated page or a slab allocated page), and exit the for loop when it is invalid.
> 
> Yes, but to me this is not what happens in the bug report you link:
> 
> | BUG: KASAN: out-of-bounds in walk_stackframe+0x130/0x2f2
> arch/riscv/kernel/stacktrace.c:59
> | Read of size 8 at addr ff20000006d37c38 by task swapper/1/0
> 
> So the read at address ff20000006d37c38 is not "normal" according to
> KASAN (you can see there is no trap, meaning the physical mapping
> exists).
> 
> | The buggy address belongs to the virtual mapping at
> |  [ff20000006d30000, ff20000006d39000) created by:
> | kernel_clone+0x118/0x896 kernel/fork.c:2909
> 
> The virtual address is legitimate since the vma exists ^
> 
> | The buggy address belongs to the physical page:
> | page:ff1c00000250dbc0 refcount:1 mapcount:0 mapping:0000000000000000
> index:0x0 pfn:0x9436f
> 
> And the physical page also exists ^
> 
> So I insist, checking that a physical mapping exists to exit the loop
> is not enough, to me, the error here is that the backtrace goes "too
> far" at an address where nothing was written before and then KASAN
> complains about that, again, we don't take any page fault here so it's
> not a problem of existing physical mapping.

Yep!

I believe what's happening here is one task unwinding another (starting from
whatever gets saved in switch_to()), and there's nothing that prevents that
other task from running concurrently and modifying/poisoning its stack. In
general trying to unwind a remote stack is racy and broken, but we're stuck
with a few bits of the kernel tryingto do that occasionally and so the arch
code needs to handle that without blowing up.

For KASAN specifically you'll need to access the stack with unchecked accesses
(e.g. using READ_ONCE_NOCHECK() to read the struct stackframe), and you'll
probably want to add some explicit checks that pointers are within stack bounds
since concurrent modification (or corruption) could result in entirely bogus
pointers.

I *think* that we do the right thing on arm64, so you might want to take a look
at arm64's unwinder in arch/arm64/kernel/stacktrace.c,
arch/arm64/include/asm/stacktrace.h, and
arch/arm64/include/asm/stacktrace/common.h.

Mark.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH] Test for riscv fixes

[Mark Rutland]

On Mon, Oct 02, 2023 at 09:13:52AM +0200, Alexandre Ghiti wrote:
> Hi Edward,
> 
> On Sat, Sep 30, 2023 at 1:06 AM Edward AD <twuufnxlz@gmail.com> wrote:
> >
> > Hi Alexandre,
> >
> > On Fri, 29 Sep 2023 10:25:59 +0200 Alexandre Ghiti <alexghiti@rivosinc.com> wrote:
> > > I'm still not convinced this will fix the kasan out-of-bounds
> > > accesses, the page can be valid but the read can happen at an offset
> > > not initialized and trigger such errors right? I still think there is
> > > something weird about the stack frame, as to me this should not happen
> > > (but admittedly I don't know much about that).
> > The added check can confirm that the physical page is invalid (whether it is a
> > vmalloc allocated page or a slab allocated page), and exit the for loop when it is invalid.
> 
> Yes, but to me this is not what happens in the bug report you link:
> 
> | BUG: KASAN: out-of-bounds in walk_stackframe+0x130/0x2f2
> arch/riscv/kernel/stacktrace.c:59
> | Read of size 8 at addr ff20000006d37c38 by task swapper/1/0
> 
> So the read at address ff20000006d37c38 is not "normal" according to
> KASAN (you can see there is no trap, meaning the physical mapping
> exists).
> 
> | The buggy address belongs to the virtual mapping at
> |  [ff20000006d30000, ff20000006d39000) created by:
> | kernel_clone+0x118/0x896 kernel/fork.c:2909
> 
> The virtual address is legitimate since the vma exists ^
> 
> | The buggy address belongs to the physical page:
> | page:ff1c00000250dbc0 refcount:1 mapcount:0 mapping:0000000000000000
> index:0x0 pfn:0x9436f
> 
> And the physical page also exists ^
> 
> So I insist, checking that a physical mapping exists to exit the loop
> is not enough, to me, the error here is that the backtrace goes "too
> far" at an address where nothing was written before and then KASAN
> complains about that, again, we don't take any page fault here so it's
> not a problem of existing physical mapping.

Yep!

I believe what's happening here is one task unwinding another (starting from
whatever gets saved in switch_to()), and there's nothing that prevents that
other task from running concurrently and modifying/poisoning its stack. In
general trying to unwind a remote stack is racy and broken, but we're stuck
with a few bits of the kernel tryingto do that occasionally and so the arch
code needs to handle that without blowing up.

For KASAN specifically you'll need to access the stack with unchecked accesses
(e.g. using READ_ONCE_NOCHECK() to read the struct stackframe), and you'll
probably want to add some explicit checks that pointers are within stack bounds
since concurrent modification (or corruption) could result in entirely bogus
pointers.

I *think* that we do the right thing on arm64, so you might want to take a look
at arm64's unwinder in arch/arm64/kernel/stacktrace.c,
arch/arm64/include/asm/stacktrace.h, and
arch/arm64/include/asm/stacktrace/common.h.

Mark.

Re: [PATCH] Test for riscv fixes

[Alexandre Ghiti]

Hi Mark,

On 02/10/2023 15:41, Mark Rutland wrote:
> On Mon, Oct 02, 2023 at 09:13:52AM +0200, Alexandre Ghiti wrote:
>> Hi Edward,
>>
>> On Sat, Sep 30, 2023 at 1:06 AM Edward AD<twuufnxlz@gmail.com>  wrote:
>>> Hi Alexandre,
>>>
>>> On Fri, 29 Sep 2023 10:25:59 +0200 Alexandre Ghiti<alexghiti@rivosinc.com>  wrote:
>>>> I'm still not convinced this will fix the kasan out-of-bounds
>>>> accesses, the page can be valid but the read can happen at an offset
>>>> not initialized and trigger such errors right? I still think there is
>>>> something weird about the stack frame, as to me this should not happen
>>>> (but admittedly I don't know much about that).
>>> The added check can confirm that the physical page is invalid (whether it is a
>>> vmalloc allocated page or a slab allocated page), and exit the for loop when it is invalid.
>> Yes, but to me this is not what happens in the bug report you link:
>>
>> | BUG: KASAN: out-of-bounds in walk_stackframe+0x130/0x2f2
>> arch/riscv/kernel/stacktrace.c:59
>> | Read of size 8 at addr ff20000006d37c38 by task swapper/1/0
>>
>> So the read at address ff20000006d37c38 is not "normal" according to
>> KASAN (you can see there is no trap, meaning the physical mapping
>> exists).
>>
>> | The buggy address belongs to the virtual mapping at
>> |  [ff20000006d30000, ff20000006d39000) created by:
>> | kernel_clone+0x118/0x896 kernel/fork.c:2909
>>
>> The virtual address is legitimate since the vma exists ^
>>
>> | The buggy address belongs to the physical page:
>> | page:ff1c00000250dbc0 refcount:1 mapcount:0 mapping:0000000000000000
>> index:0x0 pfn:0x9436f
>>
>> And the physical page also exists ^
>>
>> So I insist, checking that a physical mapping exists to exit the loop
>> is not enough, to me, the error here is that the backtrace goes "too
>> far" at an address where nothing was written before and then KASAN
>> complains about that, again, we don't take any page fault here so it's
>> not a problem of existing physical mapping.
> Yep!
>
> I believe what's happening here is one task unwinding another (starting from
> whatever gets saved in switch_to()), and there's nothing that prevents that
> other task from running concurrently and modifying/poisoning its stack. In
> general trying to unwind a remote stack is racy and broken, but we're stuck
> with a few bits of the kernel tryingto do that occasionally and so the arch
> code needs to handle that without blowing up.


Thanks for that, I had already fixed the "imprecise" unwinder (when we 
don't have a frame pointer) using READ_ONCE_NOCHECK() but I had not this 
use case in mind, so I'll fix that too.


> For KASAN specifically you'll need to access the stack with unchecked accesses
> (e.g. using READ_ONCE_NOCHECK() to read the struct stackframe), and you'll
> probably want to add some explicit checks that pointers are within stack bounds
> since concurrent modification (or corruption) could result in entirely bogus
> pointers.
>
> I *think* that we do the right thing on arm64, so you might want to take a look
> at arm64's unwinder in arch/arm64/kernel/stacktrace.c,
> arch/arm64/include/asm/stacktrace.h, and
> arch/arm64/include/asm/stacktrace/common.h.


And I'll check that for the stack bounds check.

Thanks again,

Alex


>
> Mark.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH] Test for riscv fixes

[Alexandre Ghiti]

Hi Mark,

On 02/10/2023 15:41, Mark Rutland wrote:
> On Mon, Oct 02, 2023 at 09:13:52AM +0200, Alexandre Ghiti wrote:
>> Hi Edward,
>>
>> On Sat, Sep 30, 2023 at 1:06 AM Edward AD<twuufnxlz@gmail.com>  wrote:
>>> Hi Alexandre,
>>>
>>> On Fri, 29 Sep 2023 10:25:59 +0200 Alexandre Ghiti<alexghiti@rivosinc.com>  wrote:
>>>> I'm still not convinced this will fix the kasan out-of-bounds
>>>> accesses, the page can be valid but the read can happen at an offset
>>>> not initialized and trigger such errors right? I still think there is
>>>> something weird about the stack frame, as to me this should not happen
>>>> (but admittedly I don't know much about that).
>>> The added check can confirm that the physical page is invalid (whether it is a
>>> vmalloc allocated page or a slab allocated page), and exit the for loop when it is invalid.
>> Yes, but to me this is not what happens in the bug report you link:
>>
>> | BUG: KASAN: out-of-bounds in walk_stackframe+0x130/0x2f2
>> arch/riscv/kernel/stacktrace.c:59
>> | Read of size 8 at addr ff20000006d37c38 by task swapper/1/0
>>
>> So the read at address ff20000006d37c38 is not "normal" according to
>> KASAN (you can see there is no trap, meaning the physical mapping
>> exists).
>>
>> | The buggy address belongs to the virtual mapping at
>> |  [ff20000006d30000, ff20000006d39000) created by:
>> | kernel_clone+0x118/0x896 kernel/fork.c:2909
>>
>> The virtual address is legitimate since the vma exists ^
>>
>> | The buggy address belongs to the physical page:
>> | page:ff1c00000250dbc0 refcount:1 mapcount:0 mapping:0000000000000000
>> index:0x0 pfn:0x9436f
>>
>> And the physical page also exists ^
>>
>> So I insist, checking that a physical mapping exists to exit the loop
>> is not enough, to me, the error here is that the backtrace goes "too
>> far" at an address where nothing was written before and then KASAN
>> complains about that, again, we don't take any page fault here so it's
>> not a problem of existing physical mapping.
> Yep!
>
> I believe what's happening here is one task unwinding another (starting from
> whatever gets saved in switch_to()), and there's nothing that prevents that
> other task from running concurrently and modifying/poisoning its stack. In
> general trying to unwind a remote stack is racy and broken, but we're stuck
> with a few bits of the kernel tryingto do that occasionally and so the arch
> code needs to handle that without blowing up.


Thanks for that, I had already fixed the "imprecise" unwinder (when we 
don't have a frame pointer) using READ_ONCE_NOCHECK() but I had not this 
use case in mind, so I'll fix that too.


> For KASAN specifically you'll need to access the stack with unchecked accesses
> (e.g. using READ_ONCE_NOCHECK() to read the struct stackframe), and you'll
> probably want to add some explicit checks that pointers are within stack bounds
> since concurrent modification (or corruption) could result in entirely bogus
> pointers.
>
> I *think* that we do the right thing on arm64, so you might want to take a look
> at arm64's unwinder in arch/arm64/kernel/stacktrace.c,
> arch/arm64/include/asm/stacktrace.h, and
> arch/arm64/include/asm/stacktrace/common.h.


And I'll check that for the stack bounds check.

Thanks again,

Alex


>
> Mark.

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: purvayeshi550@gmail.com

#syz test

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: purvayeshi550@gmail.com

#syz test

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: purvayeshi550@gmail.com

#syz test

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: purvayeshi550@gmail.com

#syz-test

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: kent.overstreet@linux.dev

#syz fix: bcachefs: Move bset size check before csum check

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: kent.overstreet@linux.dev

#syz fix: bcachefs: fix assert in bch2_btree_path_traverse_cached()

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: kent.overstreet@linux.dev

#syz fix: bcachefs: Fix __bch2_alloc_to_v4 copy

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: kent.overstreet@linux.dev

#syz fix:  bcachefs: fix the memory leak in exception case

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: kent.overstreet@linux.dev

#syz set subsystems: net

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: kent.overstreet@linux.dev

#syz set subsystems: mm

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: kent.overstreet@linux.dev

#syz set subsystems: mm

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: kent.overstreet@linux.dev

#syz set subsystems: mm

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: kent.overstreet@linux.dev

#syz fix: bcachefs: Don't trust sb->nr_devices in members_to_text()

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: purvayeshi550@gmail.com

#syz-test

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: purvayeshi550@gmail.com

#syz-test

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: kent.overstreet@linux.dev

#syz fix:  bcachefs: Fix possible console lock involved deadlock

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: kent.overstreet@linux.dev

#syz set subsystems: block

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: kent.overstreet@linux.dev

#syz fix: bcachefs: Move bset size check before csum check

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: kent.overstreet@linux.dev

#syz fix: bcachefs: Move bset size check before csum check

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: kent.overstreet@linux.dev

#syz fix: bcachefs: Don't allow mounting with crazy numbers of dirty journal entries

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: kent.overstreet@linux.dev

#syz set subsystems: bluetooth

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: kent.overstreet@linux.dev

#syz fix: bcachefs: Add missing validation for superblock section clean

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: kent.overstreet@linux.dev

#syz fix:  bcachefs: btree_iter: fix updates, journal overlay

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: kent.overstreet@linux.dev

#syz fix:  bcachefs: journal_entry_btree_keys_to_text() is more careful

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: kent.overstreet@linux.dev

#syz set subsystems: block fs

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: kent.overstreet@linux.dev

#syz fix: bcachefs: Fix possible console lock involved deadlock

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: kent.overstreet@linux.dev

#syz fix: bcachefs: Fix possible console lock involved deadlock

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: kent.overstreet@linux.dev

#syz fix: mm: memory: extend finish_fault() to support large folio

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: kent.overstreet@linux.dev

#syz fix: bcachefs: Increase BCH_MIN_NR_NBUCKETS

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: kent.overstreet@linux.dev

#syz fix: bcachefs: Increase BCH_MIN_NR_NBUCKETS

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: kent.overstreet@linux.dev

#syz fix:  bcachefs: Increase BCH_MIN_NR_NBUCKETS

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: kent.overstreet@linux.dev

#syz fix: bcachefs: Increase BCH_MIN_NR_NBUCKETS

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: kent.overstreet@linux.dev

#syz fix:  bcachefs: Add missing ei_last_dirtied update

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: kent.overstreet@linux.dev

#syz set subsystems: afs

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: kent.overstreet@linux.dev

#syz fix: bcachefs: btree_check_root_boundaries()

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: kent.overstreet@linux.dev

#syz fix: bcachefs: Fix incorrect transaction handling

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: kent.overstreet@linux.dev

#syz fix:  bcachefs: Ignore accounting key type larger than BCH_DISK_ACCOUNTING_TYPE_NR

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: kent.overstreet@linux.dev

#syz fix: bcachefs: Don't lock inode around page_symlink

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: abinashsinghlalotra@gmail.com

#syz test

--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -872,6 +872,11 @@ static int ax88772_bind(struct usbnet *dev, struct
usb_interface *intf)
        if (ret < 0)
                return ret;

+ if (ret >= 32) {
+ netdev_warn(dev->net, "Invalid PHY address %d, clamping\n", ret);
+ return -EINVAL;
+ }
+
        priv->phy_addr = ret;
        priv->embd_phy = ((priv->phy_addr & 0x1f) == AX_EMBD_PHY_ADDR);


--

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: abinashsinghlalotra@gmail.com

#syz test

--- a/fs/overlayfs/dir.c
+++ b/fs/overlayfs/dir.c
@@ -33,6 +33,12 @@ static int ovl_cleanup_locked(struct dentry *workdir,
struct dentry *dentry)
        struct inode *dir = d_inode(workdir);
        struct inode *inode = d_inode(dentry);

+ /* Avoid unlinking an already unlinked inode */
+ if (inode && inode->i_nlink == 0) {
+ d_drop(dentry);
+ return 0;
+ }
+
        if (ovl_is_whiteout(dentry))
                return ovl_remove_and_whiteout(workdir, dentry, true);

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: nogikh@google.com

No longer relevant
#syz invalid

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: nogikh@google.com

no longer relevant

#syz invalid

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: nogikh@google.com

#syz invalid

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: deepak.takumi.120@gmail.com

#syz test

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org.

***

Subject: 
Author: kriish.sharma2006@gmail.com

#syz test

diff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c
index 26d6c1eea559..a879e8030568 100644
--- a/fs/gfs2/rgrp.c
+++ b/fs/gfs2/rgrp.c
@@ -760,7 +760,7 @@ static int compute_bitstructs(struct gfs2_rgrpd *rgd)
        u32 bytes_left, bytes;
        int x;

-       if (!length)
+       if (!length || length > KMALLOC_MAX_SIZE / sizeof(struct
gfs2_bitmap))
                return -EINVAL;

        rgd->rd_bits = kcalloc(length, sizeof(struct gfs2_bitmap),
GFP_NOFS);

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: nooraineqbal@gmail.com

#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master

Resending this patch in the existing thread with a '#syz test:' directive
so syzbot can test it.

From 1bb35c6722b8fb03e9262f6e6530d240629a44df Mon Sep 17 00:00:00 2001
From: neqbal <nooraineqbal@gmail.com>
Date: Sun, 28 Sep 2025 03:52:44 +0530
Subject: [PATCH] x86/mm: Fix off-by-one error in set_memory

Correct end page calculation by subtracting 1 to prevent
out-of-bounds access.

Reported-by: syzbot+e34177f6091df113ef20@syzkaller.appspotmail.com
Signed-off-by: neqbal <nooraineqbal@gmail.com>
---
 arch/x86/mm/pat/set_memory.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
index d2d54b8c4dbb..daefc96403f1 100644
--- a/arch/x86/mm/pat/set_memory.c
+++ b/arch/x86/mm/pat/set_memory.c
@@ -446,7 +446,7 @@ static void cpa_flush(struct cpa_data *cpa, int cache)
 	}
 
 	start = fix_addr(__cpa_addr(cpa, 0));
-	end =   fix_addr(__cpa_addr(cpa, cpa->numpages));
+	end =   fix_addr(__cpa_addr(cpa, cpa->numpages - 1));
 	if (cpa->force_flush_all)
 		end = TLB_FLUSH_ALL;
 
-- 
2.51.0

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: jkoolstra@xs4all.nl

#syz test


 fs/ntfs3/index.c | 10 +++++-----
 fs/ntfs3/ntfs.h  |  5 ++++-
 2 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/fs/ntfs3/index.c b/fs/ntfs3/index.c
index 6d1bf890929d..2e512abc7000 100644
--- a/fs/ntfs3/index.c
+++ b/fs/ntfs3/index.c
@@ -1808,7 +1808,7 @@ indx_insert_into_buffer(struct ntfs_index *indx, struct ntfs_inode *ni,
 	CLST new_vbn;
 	__le64 t_vbn, *sub_vbn;
 	u16 sp_size;
-	void *hdr1_saved = NULL;
+	void *blk1_saved = NULL;
 
 	/* Try the most easy case. */
 	e = fnd->level - 1 == level ? fnd->de[level] : NULL;
@@ -1842,8 +1842,8 @@ indx_insert_into_buffer(struct ntfs_index *indx, struct ntfs_inode *ni,
 	memcpy(up_e, sp, sp_size);
 
 	used1 = le32_to_cpu(hdr1->used);
-	hdr1_saved = kmemdup(hdr1, used1, GFP_NOFS);
-	if (!hdr1_saved) {
+	blk1_saved = kmemdup(&n1->index->blk, used1, GFP_NOFS);
+	if (!blk1_saved) {
 		err = -ENOMEM;
 		goto out;
 	}
@@ -1924,13 +1924,13 @@ indx_insert_into_buffer(struct ntfs_index *indx, struct ntfs_inode *ni,
 		 * Undo critical operations.
 		 */
 		indx_mark_free(indx, ni, new_vbn >> indx->idx2vbn_bits);
-		memcpy(hdr1, hdr1_saved, used1);
+		memcpy(&n1->index->blk, blk1_saved, used1);
 		indx_write(indx, ni, n1, 0);
 	}
 
 out:
 	kfree(up_e);
-	kfree(hdr1_saved);
+	kfree(blk1_saved);
 
 	return err;
 }
diff --git a/fs/ntfs3/ntfs.h b/fs/ntfs3/ntfs.h
index 552b97905813..d5e2b22eacd7 100644
--- a/fs/ntfs3/ntfs.h
+++ b/fs/ntfs3/ntfs.h
@@ -754,7 +754,10 @@ static inline bool hdr_has_subnode(const struct INDEX_HDR *hdr)
 struct INDEX_BUFFER {
 	struct NTFS_RECORD_HEADER rhdr; // 'INDX'
 	__le64 vbn; // 0x10: vcn if index >= cluster or vsn id index < cluster
-	struct INDEX_HDR ihdr; // 0x18:
+	struct_group(blk,
+		struct INDEX_HDR ihdr; // 0x18:
+	        u8 data[]; // NTFS_DE entries
+	);
 };
 
 static_assert(sizeof(struct INDEX_BUFFER) == 0x28);
-- 
2.51.0

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org.

***

Subject: 
Author: jkoolstra@xs4all.nl

#syz test

---
 fs/jfs/namei.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/fs/jfs/namei.c b/fs/jfs/namei.c
index 65a218eba8fa..37cd16a423c5 100644
--- a/fs/jfs/namei.c
+++ b/fs/jfs/namei.c
@@ -1228,7 +1228,7 @@ static int jfs_rename(struct mnt_idmap *idmap, struct inode *old_dir,
 				jfs_err("jfs_rename: dtInsert returned -EIO");
 			goto out_tx;
 		}
-		if (S_ISDIR(old_ip->i_mode))
+		if (S_ISDIR(old_ip->i_mode) && old_dir != new_dir)
 			inc_nlink(new_dir);
 	}
 	/*
@@ -1244,8 +1244,9 @@ static int jfs_rename(struct mnt_idmap *idmap, struct inode *old_dir,
 		goto out_tx;
 	}
 	if (S_ISDIR(old_ip->i_mode)) {
-		drop_nlink(old_dir);
 		if (old_dir != new_dir) {
+			drop_nlink(old_dir);
+
 			/*
 			 * Change inode number of parent for moved directory
 			 */
-- 
2.51.0

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org.

***

Subject: 
Author: jkoolstra@xs4all.nl

#syz test

---
 fs/jfs/namei.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/fs/jfs/namei.c b/fs/jfs/namei.c
index 65a218eba8fa..7879c049632b 100644
--- a/fs/jfs/namei.c
+++ b/fs/jfs/namei.c
@@ -1228,7 +1228,7 @@ static int jfs_rename(struct mnt_idmap *idmap, struct inode *old_dir,
 				jfs_err("jfs_rename: dtInsert returned -EIO");
 			goto out_tx;
 		}
-		if (S_ISDIR(old_ip->i_mode))
+		if (S_ISDIR(old_ip->i_mode) && old_dir != new_dir)
 			inc_nlink(new_dir);
 	}
 	/*
@@ -1244,7 +1244,9 @@ static int jfs_rename(struct mnt_idmap *idmap, struct inode *old_dir,
 		goto out_tx;
 	}
 	if (S_ISDIR(old_ip->i_mode)) {
-		drop_nlink(old_dir);
+		if (new_ip || old_dir != new_dir)
+			drop_nlink(old_dir);
+
 		if (old_dir != new_dir) {
 			/*
 			 * Change inode number of parent for moved directory
-- 
2.51.0

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org.

***

Subject: 
Author: jkoolstra@xs4all.nl

#syz test

---
fs/minix/namei.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/minix/namei.c b/fs/minix/namei.c
index 8938536d8d3c..86779a6ec1a7 100644
--- a/fs/minix/namei.c
+++ b/fs/minix/namei.c
@@ -224,7 +224,7 @@ static int minix_rename(struct mnt_idmap *idmap,
err = minix_add_link(new_dentry, old_inode);
if (err)
goto out_dir;
- if (dir_de)
+ if (dir_de && old_dir != new_dir)
inode_inc_link_count(new_dir);
}
@@ -236,7 +236,7 @@ static int minix_rename(struct mnt_idmap *idmap,
if (dir_de) {
err = minix_set_link(dir_de, dir_folio, new_dir);
- if (!err)
+ if (!err && (new_inode || old_dir != new_dir))
inode_dec_link_count(old_dir);
}
out_dir:
-- 
2.51.0

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org.

***

Subject: 
Author: jkoolstra@xs4all.nl

#syz test

---
 fs/minix/inode.c | 14 ++++++++++++++
 fs/minix/namei.c | 22 ++++++++++++++--------
 2 files changed, 28 insertions(+), 8 deletions(-)

diff --git a/fs/minix/inode.c b/fs/minix/inode.c
index f007e389d5d2..e27907fc9bf2 100644
--- a/fs/minix/inode.c
+++ b/fs/minix/inode.c
@@ -517,6 +517,13 @@ static struct inode *V1_minix_iget(struct inode *inode)
 		iget_failed(inode);
 		return ERR_PTR(-ESTALE);
 	}
+	if (S_ISDIR(raw_inode->i_mode) && raw_inode->i_nlinks == 1) {
+		printk("MINIX-fs: directory inode (%lu) has single i_nlink\n",
+		       inode->i_ino);
+		brelse(bh);
+		iget_failed(inode);
+		return ERR_PTR(-EIO);
+	}
 	inode->i_mode = raw_inode->i_mode;
 	i_uid_write(inode, raw_inode->i_uid);
 	i_gid_write(inode, raw_inode->i_gid);
@@ -555,6 +562,13 @@ static struct inode *V2_minix_iget(struct inode *inode)
 		iget_failed(inode);
 		return ERR_PTR(-ESTALE);
 	}
+	if (S_ISDIR(raw_inode->i_mode) && raw_inode->i_nlinks == 1) {
+		printk("MINIX-fs: directory inode (%lu) has single i_nlink\n",
+		       inode->i_ino);
+		brelse(bh);
+		iget_failed(inode);
+		return ERR_PTR(-EIO);
+	}
 	inode->i_mode = raw_inode->i_mode;
 	i_uid_write(inode, raw_inode->i_uid);
 	i_gid_write(inode, raw_inode->i_gid);
diff --git a/fs/minix/namei.c b/fs/minix/namei.c
index 8938536d8d3c..8297ee6651a1 100644
--- a/fs/minix/namei.c
+++ b/fs/minix/namei.c
@@ -161,15 +161,21 @@ static int minix_unlink(struct inode * dir, struct dentry *dentry)
 static int minix_rmdir(struct inode * dir, struct dentry *dentry)
 {
 	struct inode * inode = d_inode(dentry);
-	int err = -ENOTEMPTY;
-
-	if (minix_empty_dir(inode)) {
-		err = minix_unlink(dir, dentry);
-		if (!err) {
-			inode_dec_link_count(dir);
-			inode_dec_link_count(inode);
-		}
+	int err = -EIO;
+
+	if (dir->i_nlink <= 2)
+		goto out;
+
+	err = -ENOTEMPTY;
+	if (!minix_empty_dir(inode))
+		goto out;
+
+	err = minix_unlink(dir, dentry);
+	if (!err) {
+		inode_dec_link_count(dir);
+		inode_dec_link_count(inode);
 	}
+out:
 	return err;
 }
 
-- 
2.51.0

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: jkoolstra@xs4all.nl

#syz test

---
 fs/minix/inode.c | 14 ++++++++++++++
 fs/minix/namei.c | 22 ++++++++++++++--------
 2 files changed, 28 insertions(+), 8 deletions(-)

diff --git a/fs/minix/inode.c b/fs/minix/inode.c
index f007e389d5d2..e27907fc9bf2 100644
--- a/fs/minix/inode.c
+++ b/fs/minix/inode.c
@@ -517,6 +517,13 @@ static struct inode *V1_minix_iget(struct inode *inode)
 		iget_failed(inode);
 		return ERR_PTR(-ESTALE);
 	}
+	if (S_ISDIR(raw_inode->i_mode) && raw_inode->i_nlinks == 1) {
+		printk("MINIX-fs: directory inode (%lu) has single i_nlink\n",
+		       inode->i_ino);
+		brelse(bh);
+		iget_failed(inode);
+		return ERR_PTR(-EIO);
+	}
 	inode->i_mode = raw_inode->i_mode;
 	i_uid_write(inode, raw_inode->i_uid);
 	i_gid_write(inode, raw_inode->i_gid);
@@ -555,6 +562,13 @@ static struct inode *V2_minix_iget(struct inode *inode)
 		iget_failed(inode);
 		return ERR_PTR(-ESTALE);
 	}
+	if (S_ISDIR(raw_inode->i_mode) && raw_inode->i_nlinks == 1) {
+		printk("MINIX-fs: directory inode (%lu) has single i_nlink\n",
+		       inode->i_ino);
+		brelse(bh);
+		iget_failed(inode);
+		return ERR_PTR(-EIO);
+	}
 	inode->i_mode = raw_inode->i_mode;
 	i_uid_write(inode, raw_inode->i_uid);
 	i_gid_write(inode, raw_inode->i_gid);
diff --git a/fs/minix/namei.c b/fs/minix/namei.c
index 8938536d8d3c..8297ee6651a1 100644
--- a/fs/minix/namei.c
+++ b/fs/minix/namei.c
@@ -161,15 +161,21 @@ static int minix_unlink(struct inode * dir, struct dentry *dentry)
 static int minix_rmdir(struct inode * dir, struct dentry *dentry)
 {
 	struct inode * inode = d_inode(dentry);
-	int err = -ENOTEMPTY;
-
-	if (minix_empty_dir(inode)) {
-		err = minix_unlink(dir, dentry);
-		if (!err) {
-			inode_dec_link_count(dir);
-			inode_dec_link_count(inode);
-		}
+	int err = -EIO;
+
+	if (dir->i_nlink <= 2)
+		goto out;
+
+	err = -ENOTEMPTY;
+	if (!minix_empty_dir(inode))
+		goto out;
+
+	err = minix_unlink(dir, dentry);
+	if (!err) {
+		inode_dec_link_count(dir);
+		inode_dec_link_count(inode);
 	}
+out:
 	return err;
 }
 
-- 
2.51.0

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: clf700383@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master

From 6dc2deb09faf7d53707cc9e75e175b09644fd181 Mon Sep 17 00:00:00 2001
From: clingfei <clf700383@gmail.com>
Date: Mon, 20 Oct 2025 13:48:54 +0800
Subject: [PATCH] fix integer overflow in set_ipsecrequest

syzbot reported a kernel BUG in set_ipsecrequest() due to an skb_over_panic.

The mp->new_family and mp->old_family is u16, while set_ipsecrequest receives
family as uint8_t,  causing a integer overflow and the later size_req calculation
error, which exceeds the size used in alloc_skb, and ultimately triggered the
kernel bug in skb_put.

Reported-by: syzbot+be97dd4da14ae88b6ba4@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=be97dd4da14ae88b6ba4
Signed-off-by: Cheng Lingfei <clf700383@gmail.com>
---
 net/key/af_key.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/key/af_key.c b/net/key/af_key.c
index 2ebde0352245..08f4cde01994 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -3518,7 +3518,7 @@ static int set_sadb_kmaddress(struct sk_buff *skb, const struct xfrm_kmaddress *
 
 static int set_ipsecrequest(struct sk_buff *skb,
 			    uint8_t proto, uint8_t mode, int level,
-			    uint32_t reqid, uint8_t family,
+			    uint32_t reqid, uint16_t family,
 			    const xfrm_address_t *src, const xfrm_address_t *dst)
 {
 	struct sadb_x_ipsecrequest *rq;
-- 
2.34.1

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org.

***

Subject: 
Author: zlatistiv@gmail.com

#syz test

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org.

***

Subject: 
Author: kubik.bartlomiej@gmail.com

#syz test

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org.

***

Subject: 
Author: jkoolstra@xs4all.nl

#syz test

diff --git a/fs/jfs/jfs_dtree.c b/fs/jfs/jfs_dtree.c
index 0ab83bb7bbdf..07dd01c79ca2 100644
--- a/fs/jfs/jfs_dtree.c
+++ b/fs/jfs/jfs_dtree.c
@@ -170,8 +170,8 @@ static void dtGetKey(dtpage_t * p, int i, struct component_name * key,
 static int ciGetLeafPrefixKey(dtpage_t * lp, int li, dtpage_t * rp,
 			      int ri, struct component_name * key, int flag);
 
-static void dtInsertEntry(dtpage_t * p, int index, struct component_name * key,
-			  ddata_t * data, struct dt_lock **);
+static int dtInsertEntry(dtpage_t * p, int index, struct component_name * key,
+			 ddata_t * data, struct dt_lock **);
 
 static void dtMoveEntry(dtpage_t * sp, int si, dtpage_t * dp,
 			struct dt_lock ** sdtlock, struct dt_lock ** ddtlock,
@@ -891,7 +891,8 @@ int dtInsert(tid_t tid, struct inode *ip,
 	lv->length = 1;
 	dtlck->index++;
 
-	dtInsertEntry(p, index, name, &data, &dtlck);
+	if (!(rc = dtInsertEntry(p, index, name, &data, &dtlck)))
+		return rc;
 
 	/* linelock stbl of non-root leaf page */
 	if (!(p->header.flag & BT_ROOT)) {
@@ -3627,7 +3628,7 @@ static void dtGetKey(dtpage_t * p, int i,	/* entry index */
  *
  * return: entry slot index
  */
-static void dtInsertEntry(dtpage_t * p, int index, struct component_name * key,
+static int dtInsertEntry(dtpage_t * p, int index, struct component_name * key,
 			  ddata_t * data, struct dt_lock ** dtlock)
 {
 	struct dtslot *h, *t;
@@ -3649,6 +3650,10 @@ static void dtInsertEntry(dtpage_t * p, int index, struct component_name * key,
 
 	/* allocate a free slot */
 	hsi = fsi = p->header.freelist;
+	if (fsi >= p->header.maxslot) {
+		jfs_err("Encountered corrupted dtpage before insert");
+		return -EIO;
+	}
 	h = &p->slot[fsi];
 	p->header.freelist = h->next;
 	--p->header.freecnt;
@@ -3697,6 +3702,10 @@ static void dtInsertEntry(dtpage_t * p, int index, struct component_name * key,
 	while (klen) {
 		/* get free slot */
 		fsi = p->header.freelist;
+		if (fsi >= p->header.maxslot) {
+			jfs_err("Encountered corrupted dtpage before insert");
+			return -EIO;
+		}
 		t = &p->slot[fsi];
 		p->header.freelist = t->next;
 		--p->header.freecnt;
@@ -3774,6 +3783,8 @@ static void dtInsertEntry(dtpage_t * p, int index, struct component_name * key,
 
 	/* advance next available entry index of stbl */
 	++p->header.nextindex;
+
+	return 0;
 }

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org.

***

Subject: 
Author: jkoolstra@xs4all.nl

#syz test

---
 fs/jfs/jfs_dtree.c | 22 +++++++++++++++++-----
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/fs/jfs/jfs_dtree.c b/fs/jfs/jfs_dtree.c
index 0ab83bb7bbdf..e919de01c42a 100644
--- a/fs/jfs/jfs_dtree.c
+++ b/fs/jfs/jfs_dtree.c
@@ -170,8 +170,8 @@ static void dtGetKey(dtpage_t * p, int i, struct component_name * key,
 static int ciGetLeafPrefixKey(dtpage_t * lp, int li, dtpage_t * rp,
 			      int ri, struct component_name * key, int flag);
 
-static void dtInsertEntry(dtpage_t * p, int index, struct component_name * key,
-			  ddata_t * data, struct dt_lock **);
+static int dtInsertEntry(dtpage_t * p, int index, struct component_name * key,
+			 ddata_t * data, struct dt_lock **);
 
 static void dtMoveEntry(dtpage_t * sp, int si, dtpage_t * dp,
 			struct dt_lock ** sdtlock, struct dt_lock ** ddtlock,
@@ -891,7 +891,8 @@ int dtInsert(tid_t tid, struct inode *ip,
 	lv->length = 1;
 	dtlck->index++;
 
-	dtInsertEntry(p, index, name, &data, &dtlck);
+	if (!(rc = dtInsertEntry(p, index, name, &data, &dtlck)))
+		return rc;
 
 	/* linelock stbl of non-root leaf page */
 	if (!(p->header.flag & BT_ROOT)) {
@@ -3625,9 +3626,10 @@ static void dtGetKey(dtpage_t * p, int i,	/* entry index */
  * function: allocate free slot(s) and
  *	     write a leaf/internal entry
  *
- * return: entry slot index
+ * * return: 0 - success;
+ *	   errno - failure;
  */
-static void dtInsertEntry(dtpage_t * p, int index, struct component_name * key,
+static int dtInsertEntry(dtpage_t * p, int index, struct component_name * key,
 			  ddata_t * data, struct dt_lock ** dtlock)
 {
 	struct dtslot *h, *t;
@@ -3649,6 +3651,10 @@ static void dtInsertEntry(dtpage_t * p, int index, struct component_name * key,
 
 	/* allocate a free slot */
 	hsi = fsi = p->header.freelist;
+	if (fsi >= ((p->header.flag & BT_ROOT) ? DTROOTMAXSLOT : p->header.maxslot)) {
+		jfs_err("Encountered corrupted dtpage before insert");
+		return -EIO;
+	}
 	h = &p->slot[fsi];
 	p->header.freelist = h->next;
 	--p->header.freecnt;
@@ -3697,6 +3703,10 @@ static void dtInsertEntry(dtpage_t * p, int index, struct component_name * key,
 	while (klen) {
 		/* get free slot */
 		fsi = p->header.freelist;
+		if (fsi >= ((p->header.flag & BT_ROOT) ? DTROOTMAXSLOT : p->header.maxslot)) {
+			jfs_err("Encountered corrupted dtpage before insert");
+			return -EIO;
+		}
 		t = &p->slot[fsi];
 		p->header.freelist = t->next;
 		--p->header.freecnt;
@@ -3774,6 +3784,8 @@ static void dtInsertEntry(dtpage_t * p, int index, struct component_name * key,
 
 	/* advance next available entry index of stbl */
 	++p->header.nextindex;
+
+	return 0;
 }
 
 
-- 
2.51.1.dirty

Re: Forwarded:

[Al Viro]

On Tue, Oct 28, 2025 at 10:25:20AM -0700, syzbot wrote:
> For archival purposes, forwarding an incoming command email to
> linux-kernel@vger.kernel.org.

For fuck sake, either generate a more useful subject, or take
that to a separate list just for syzbot use.

Do you really intend to end up in a bunch of .procmailrc?

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: jkoolstra@xs4all.nl

#syz test

---
 fs/jfs/jfs_dtree.c | 22 +++++++++++++++++-----
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/fs/jfs/jfs_dtree.c b/fs/jfs/jfs_dtree.c
index 0ab83bb7bbdf..e919de01c42a 100644
--- a/fs/jfs/jfs_dtree.c
+++ b/fs/jfs/jfs_dtree.c
@@ -170,8 +170,8 @@ static void dtGetKey(dtpage_t * p, int i, struct component_name * key,
 static int ciGetLeafPrefixKey(dtpage_t * lp, int li, dtpage_t * rp,
 			      int ri, struct component_name * key, int flag);
 
-static void dtInsertEntry(dtpage_t * p, int index, struct component_name * key,
-			  ddata_t * data, struct dt_lock **);
+static int dtInsertEntry(dtpage_t * p, int index, struct component_name * key,
+			 ddata_t * data, struct dt_lock **);
 
 static void dtMoveEntry(dtpage_t * sp, int si, dtpage_t * dp,
 			struct dt_lock ** sdtlock, struct dt_lock ** ddtlock,
@@ -891,7 +891,8 @@ int dtInsert(tid_t tid, struct inode *ip,
 	lv->length = 1;
 	dtlck->index++;
 
-	dtInsertEntry(p, index, name, &data, &dtlck);
+	if (!(rc = dtInsertEntry(p, index, name, &data, &dtlck)))
+		return rc;
 
 	/* linelock stbl of non-root leaf page */
 	if (!(p->header.flag & BT_ROOT)) {
@@ -3625,9 +3626,10 @@ static void dtGetKey(dtpage_t * p, int i,	/* entry index */
  * function: allocate free slot(s) and
  *	     write a leaf/internal entry
  *
- * return: entry slot index
+ * * return: 0 - success;
+ *	   errno - failure;
  */
-static void dtInsertEntry(dtpage_t * p, int index, struct component_name * key,
+static int dtInsertEntry(dtpage_t * p, int index, struct component_name * key,
 			  ddata_t * data, struct dt_lock ** dtlock)
 {
 	struct dtslot *h, *t;
@@ -3649,6 +3651,10 @@ static void dtInsertEntry(dtpage_t * p, int index, struct component_name * key,
 
 	/* allocate a free slot */
 	hsi = fsi = p->header.freelist;
+	if (fsi >= ((p->header.flag & BT_ROOT) ? DTROOTMAXSLOT : p->header.maxslot)) {
+		jfs_err("Encountered corrupted dtpage before insert");
+		return -EIO;
+	}
 	h = &p->slot[fsi];
 	p->header.freelist = h->next;
 	--p->header.freecnt;
@@ -3697,6 +3703,10 @@ static void dtInsertEntry(dtpage_t * p, int index, struct component_name * key,
 	while (klen) {
 		/* get free slot */
 		fsi = p->header.freelist;
+		if (fsi >= ((p->header.flag & BT_ROOT) ? DTROOTMAXSLOT : p->header.maxslot)) {
+			jfs_err("Encountered corrupted dtpage before insert");
+			return -EIO;
+		}
 		t = &p->slot[fsi];
 		p->header.freelist = t->next;
 		--p->header.freecnt;
@@ -3774,6 +3784,8 @@ static void dtInsertEntry(dtpage_t * p, int index, struct component_name * key,
 
 	/* advance next available entry index of stbl */
 	++p->header.nextindex;
+
+	return 0;
 }
 
 
-- 
2.51.1.dirty

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: jkoolstra@xs4all.nl

#syz test

---
 fs/minix/minix.h |  2 ++
 fs/minix/namei.c | 26 ++++++++++++++++++--------
 2 files changed, 20 insertions(+), 8 deletions(-)

diff --git a/fs/minix/minix.h b/fs/minix/minix.h
index d54273c3c9ff..ce62cb61186d 100644
--- a/fs/minix/minix.h
+++ b/fs/minix/minix.h
@@ -168,4 +168,6 @@ static inline int minix_test_bit(int nr, const void *vaddr)
 
 #endif
 
+#define EFSCORRUPTED	EUCLEAN		/* Filesystem is corrupted */
+
 #endif /* FS_MINIX_H */
diff --git a/fs/minix/namei.c b/fs/minix/namei.c
index 8938536d8d3c..a8d5a7e22b7b 100644
--- a/fs/minix/namei.c
+++ b/fs/minix/namei.c
@@ -161,15 +161,25 @@ static int minix_unlink(struct inode * dir, struct dentry *dentry)
 static int minix_rmdir(struct inode * dir, struct dentry *dentry)
 {
 	struct inode * inode = d_inode(dentry);
-	int err = -ENOTEMPTY;
-
-	if (minix_empty_dir(inode)) {
-		err = minix_unlink(dir, dentry);
-		if (!err) {
-			inode_dec_link_count(dir);
-			inode_dec_link_count(inode);
-		}
+	int err = -EFSCORRUPTED;
+
+	if (dir->i_nlink <= 2) {
+		printk(KERN_CRIT "minix-fs error: directory inode has "
+		       "corrupted nlink");
+		goto out;
 	}
+
+	err = -ENOTEMPTY;
+	if (!minix_empty_dir(inode))
+		goto out;
+
+	err = minix_unlink(dir, dentry);
+	if (!err) {
+		inode_dec_link_count(dir);
+		inode_dec_link_count(inode);
+ 	}
+
+out:
 	return err;
 }
 
-- 
2.51.1.dirty

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: jkoolstra@xs4all.nl

#syz test

---

diff --git a/fs/minix/namei.c b/fs/minix/namei.c
index a8d5a7e22b7b..8648d860ef0c 100644
--- a/fs/minix/namei.c
+++ b/fs/minix/namei.c
@@ -218,6 +218,13 @@ static int minix_rename(struct mnt_idmap *idmap,
                if (dir_de && !minix_empty_dir(new_inode))
                        goto out_dir;
 
+               err = -EFSCORRUPTED;
+               if (dir_de && new_inode->i_nlink != 2) {
+                       printk(KERN_CRIT "minix-fs error: directory inode has "
+                              "corrupted nlink");
+                       goto out_dir;
+               }
+
                err = -ENOENT;
                new_de = minix_find_entry(new_dentry, &new_folio);
                if (!new_de)

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: jkoolstra@xs4all.nl

#syz test

---
diff --git a/fs/minix/minix.h b/fs/minix/minix.h
index d54273c3c9ff..ce62cb61186d 100644
--- a/fs/minix/minix.h
+++ b/fs/minix/minix.h
@@ -168,4 +168,6 @@ static inline int minix_test_bit(int nr, const void *vaddr)
 
 #endif
 
+#define EFSCORRUPTED   EUCLEAN         /* Filesystem is corrupted */
+
 #endif /* FS_MINIX_H */

diff --git a/fs/minix/namei.c b/fs/minix/namei.c
index a8d5a7e22b7b..8648d860ef0c 100644
--- a/fs/minix/namei.c
+++ b/fs/minix/namei.c
@@ -218,6 +218,13 @@ static int minix_rename(struct mnt_idmap *idmap,
                if (dir_de && !minix_empty_dir(new_inode))
                        goto out_dir;
 
+               err = -EFSCORRUPTED;
+               if (dir_de && new_inode->i_nlink != 2) {
+                       printk(KERN_CRIT "minix-fs error: directory inode has "
+                              "corrupted nlink");
+                       goto out_dir;
+               }
+
                err = -ENOENT;
                new_de = minix_find_entry(new_dentry, &new_folio);
                if (!new_de)

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: jkoolstra@xs4all.nl

#syz test

---

diff --git a/fs/minix/minix.h b/fs/minix/minix.h
index d54273c3c9ff..ce62cb61186d 100644
--- a/fs/minix/minix.h
+++ b/fs/minix/minix.h
@@ -168,4 +168,6 @@ static inline int minix_test_bit(int nr, const void *vaddr)
 
 #endif
 
+#define EFSCORRUPTED   EUCLEAN         /* Filesystem is corrupted */
+
 #endif /* FS_MINIX_H */
diff --git a/fs/minix/namei.c b/fs/minix/namei.c
index 8938536d8d3c..493a75eff2c9 100644
--- a/fs/minix/namei.c
+++ b/fs/minix/namei.c
@@ -208,6 +218,13 @@ static int minix_rename(struct mnt_idmap *idmap,
                if (dir_de && !minix_empty_dir(new_inode))
                        goto out_dir;
 
+               err = -EFSCORRUPTED;
+               if (new_inode->i_nlink == 0 || (dir_de && new_inode->i_nlink != 2)) {
+                       printk(KERN_CRIT "minix-fs error: inode (ino: %ld) "
+                              "has corrupted nlink", new_inode->i_ino);
+                       goto out_dir;
+               }
+
                err = -ENOENT;
                new_de = minix_find_entry(new_dentry, &new_folio);
                if (!new_de)

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: jkoolstra@xs4all.nl

#syz test

---

diff --git a/fs/ntfs3/super.c b/fs/ntfs3/super.c
index aae1f32f4dab..f193912d8632 100644
--- a/fs/ntfs3/super.c
+++ b/fs/ntfs3/super.c
@@ -704,8 +704,8 @@ static void ntfs_put_super(struct super_block *sb)
        ntfs_set_state(sbi, NTFS_DIRTY_CLEAR);
 
        if (sbi->options) {
+               kfree(sbi->options->nls_name);
                unload_nls(sbi->options->nls);
-               kfree(sbi->options->nls);
                kfree(sbi->options);
                sbi->options = NULL;
        }
@@ -1670,8 +1670,8 @@ static int ntfs_fill_super(struct super_block *sb, struct fs_context *fc)
        iput(inode);
 out:
        if (sbi && sbi->options) {
+               kfree(sbi->options->nls_name);
                unload_nls(sbi->options->nls);
-               kfree(sbi->options->nls);
                kfree(sbi->options);
                sbi->options = NULL;
        }

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: jkoolstra@xs4all.nl

#syz test

---
diff --git a/fs/minix/minix.h b/fs/minix/minix.h
index d54273c3c9ff..ce62cb61186d 100644
--- a/fs/minix/minix.h
+++ b/fs/minix/minix.h
@@ -168,4 +168,6 @@ static inline int minix_test_bit(int nr, const void *vaddr)
 
 #endif
 
+#define EFSCORRUPTED   EUCLEAN         /* Filesystem is corrupted */
+
 #endif /* FS_MINIX_H */
diff --git a/fs/minix/namei.c b/fs/minix/namei.c
index a8d5a7e22b7b..f18f7474aca4 100644
--- a/fs/minix/namei.c
+++ b/fs/minix/namei.c
@@ -145,6 +145,12 @@ static int minix_unlink(struct inode * dir, struct dentry *dentry)
        struct minix_dir_entry * de;
        int err;
 
+       if (inode->i_nlink < 1) {
+               printk(KERN_CRIT "minix-fs error: inode (ino: %ld) "
+                      "has corrupted nlink", inode->i_ino);
+               return -EFSCORRUPTED;
+       }
+
        de = minix_find_entry(dentry, &folio);
        if (!de)
                return -ENOENT;
@@ -218,6 +224,13 @@ static int minix_rename(struct mnt_idmap *idmap,
                if (dir_de && !minix_empty_dir(new_inode))
                        goto out_dir;
 
+               err = -EFSCORRUPTED;
+               if (new_inode->i_nlink == 0 || (dir_de && new_inode->i_nlink != 2)) {
+                       printk(KERN_CRIT "minix-fs error: inode (ino: %ld) "
+                              "has corrupted nlink", new_inode->i_ino);
+                       goto out_dir;
+               }
+
                err = -ENOENT;
                new_de = minix_find_entry(new_dentry, &new_folio);
                if (!new_de)

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: jkoolstra@xs4all.nl

#syz test

---

diff --git a/fs/hfs/dir.c b/fs/hfs/dir.c
index 86a6b317b474..ee1760305380 100644
--- a/fs/hfs/dir.c
+++ b/fs/hfs/dir.c
@@ -196,8 +196,8 @@ static int hfs_create(struct mnt_idmap *idmap, struct inode *dir,
        int res;
 
        inode = hfs_new_inode(dir, &dentry->d_name, mode);
-       if (!inode)
-               return -ENOMEM;
+       if (IS_ERR(inode))
+               return PTR_ERR(inode);
 
        res = hfs_cat_create(inode->i_ino, dir, &dentry->d_name, inode);
        if (res) {
@@ -226,8 +226,8 @@ static struct dentry *hfs_mkdir(struct mnt_idmap *idmap, struct inode *dir,
        int res;
 
        inode = hfs_new_inode(dir, &dentry->d_name, S_IFDIR | mode);
-       if (!inode)
-               return ERR_PTR(-ENOMEM);
+       if (IS_ERR(inode))
+               return ERR_CAST(inode);
 
        res = hfs_cat_create(inode->i_ino, dir, &dentry->d_name, inode);
        if (res) {
diff --git a/fs/hfs/hfs_fs.h b/fs/hfs/hfs_fs.h
index fff149af89da..6808b1316b60 100644
--- a/fs/hfs/hfs_fs.h
+++ b/fs/hfs/hfs_fs.h
@@ -273,4 +273,6 @@ static inline void hfs_bitmap_dirty(struct super_block *sb)
        __bh;                                           \
 })
 
+#define EFSCORRUPTED   EUCLEAN         /* Filesystem is corrupted */
+
 #endif
diff --git a/fs/hfs/inode.c b/fs/hfs/inode.c
index 9cd449913dc8..ef46a2d29d6a 100644
--- a/fs/hfs/inode.c
+++ b/fs/hfs/inode.c
@@ -188,7 +188,7 @@ struct inode *hfs_new_inode(struct inode *dir, const struct qstr *name, umode_t
        s64 folder_count;
 
        if (!inode)
-               return NULL;
+               return ERR_PTR(-ENOMEM);
 
        mutex_init(&HFS_I(inode)->extents_lock);
        INIT_LIST_HEAD(&HFS_I(inode)->open_dir_list);
@@ -209,7 +209,10 @@ struct inode *hfs_new_inode(struct inode *dir, const struct qstr *name, umode_t
        if (S_ISDIR(mode)) {
                inode->i_size = 2;
                folder_count = atomic64_inc_return(&HFS_SB(sb)->folder_count);
-               BUG_ON(folder_count > U32_MAX);
+               if (folder_count > U32_MAX) {
+                       printk(KERN_CRIT "hfs error: folder count on super block is corrupt");
+                       return ERR_PTR(-EFSCORRUPTED);
+               }
                if (dir->i_ino == HFS_ROOT_CNID)
                        HFS_SB(sb)->root_dirs++;
                inode->i_op = &hfs_dir_inode_operations;
@@ -219,7 +222,10 @@ struct inode *hfs_new_inode(struct inode *dir, const struct qstr *name, umode_t
        } else if (S_ISREG(mode)) {
                HFS_I(inode)->clump_blocks = HFS_SB(sb)->clumpablks;
                file_count = atomic64_inc_return(&HFS_SB(sb)->file_count);
-               BUG_ON(file_count > U32_MAX);
+               if (file_count > U32_MAX) {
+                       printk(KERN_CRIT "hfs error: file count on super block is corrupt");
+                       return ERR_PTR(-EFSCORRUPTED);
+               }
                if (dir->i_ino == HFS_ROOT_CNID)
                        HFS_SB(sb)->root_files++;
                inode->i_op = &hfs_file_inode_operations;

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: jkoolstra@xs4all.nl

#syz test

---

diff --git a/fs/hfs/dir.c b/fs/hfs/dir.c
index 86a6b317b474..ee1760305380 100644
--- a/fs/hfs/dir.c
+++ b/fs/hfs/dir.c
@@ -196,8 +196,8 @@ static int hfs_create(struct mnt_idmap *idmap, struct inode *dir,
 	int res;
 
 	inode = hfs_new_inode(dir, &dentry->d_name, mode);
-	if (!inode)
-		return -ENOMEM;
+	if (IS_ERR(inode))
+		return PTR_ERR(inode);
 
 	res = hfs_cat_create(inode->i_ino, dir, &dentry->d_name, inode);
 	if (res) {
@@ -226,8 +226,8 @@ static struct dentry *hfs_mkdir(struct mnt_idmap *idmap, struct inode *dir,
 	int res;
 
 	inode = hfs_new_inode(dir, &dentry->d_name, S_IFDIR | mode);
-	if (!inode)
-		return ERR_PTR(-ENOMEM);
+	if (IS_ERR(inode))
+		return ERR_CAST(inode);
 
 	res = hfs_cat_create(inode->i_ino, dir, &dentry->d_name, inode);
 	if (res) {
diff --git a/fs/hfs/hfs_fs.h b/fs/hfs/hfs_fs.h
index fff149af89da..6808b1316b60 100644
--- a/fs/hfs/hfs_fs.h
+++ b/fs/hfs/hfs_fs.h
@@ -273,4 +273,6 @@ static inline void hfs_bitmap_dirty(struct super_block *sb)
 	__bh;						\
 })
 
+#define EFSCORRUPTED   EUCLEAN         /* Filesystem is corrupted */
+
 #endif
diff --git a/fs/hfs/inode.c b/fs/hfs/inode.c
index 9cd449913dc8..cb74904994cc 100644
--- a/fs/hfs/inode.c
+++ b/fs/hfs/inode.c
@@ -186,16 +186,22 @@ struct inode *hfs_new_inode(struct inode *dir, const struct qstr *name, umode_t
 	s64 next_id;
 	s64 file_count;
 	s64 folder_count;
+	int err = -ENOMEM;
 
 	if (!inode)
-		return NULL;
+		goto out_err;
+
+	err = -EFSCORRUPTED;
 
 	mutex_init(&HFS_I(inode)->extents_lock);
 	INIT_LIST_HEAD(&HFS_I(inode)->open_dir_list);
 	spin_lock_init(&HFS_I(inode)->open_dir_lock);
 	hfs_cat_build_key(sb, (btree_key *)&HFS_I(inode)->cat_key, dir->i_ino, name);
 	next_id = atomic64_inc_return(&HFS_SB(sb)->next_id);
-	BUG_ON(next_id > U32_MAX);
+	if (next_id > U32_MAX) {
+		printk(KERN_CRIT "hfs error: next file id on super block is corrupt");
+		goto out_discard;
+	}
 	inode->i_ino = (u32)next_id;
 	inode->i_mode = mode;
 	inode->i_uid = current_fsuid();
@@ -209,7 +215,10 @@ struct inode *hfs_new_inode(struct inode *dir, const struct qstr *name, umode_t
 	if (S_ISDIR(mode)) {
 		inode->i_size = 2;
 		folder_count = atomic64_inc_return(&HFS_SB(sb)->folder_count);
-		BUG_ON(folder_count > U32_MAX);
+		if (folder_count > U32_MAX) {
+			printk(KERN_CRIT "hfs error: folder count on super block is corrupt");
+			goto out_discard;
+		}
 		if (dir->i_ino == HFS_ROOT_CNID)
 			HFS_SB(sb)->root_dirs++;
 		inode->i_op = &hfs_dir_inode_operations;
@@ -219,7 +228,10 @@ struct inode *hfs_new_inode(struct inode *dir, const struct qstr *name, umode_t
 	} else if (S_ISREG(mode)) {
 		HFS_I(inode)->clump_blocks = HFS_SB(sb)->clumpablks;
 		file_count = atomic64_inc_return(&HFS_SB(sb)->file_count);
-		BUG_ON(file_count > U32_MAX);
+		if (file_count > U32_MAX) {
+			printk(KERN_CRIT "hfs error: file count on super block is corrupt");
+			goto out_discard;
+		}
 		if (dir->i_ino == HFS_ROOT_CNID)
 			HFS_SB(sb)->root_files++;
 		inode->i_op = &hfs_file_inode_operations;
@@ -243,6 +255,11 @@ struct inode *hfs_new_inode(struct inode *dir, const struct qstr *name, umode_t
 	hfs_mark_mdb_dirty(sb);
 
 	return inode;
+
+	out_discard:
+		iput(inode);	
+	out_err:
+		return ERR_PTR(err); 
 }
 
 void hfs_delete_inode(struct inode *inode)

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org.

***

Subject: 
Author: jkoolstra@xs4all.nl

#syz test

---

diff --git a/fs/hfs/dir.c b/fs/hfs/dir.c
index 86a6b317b474..ee1760305380 100644
--- a/fs/hfs/dir.c
+++ b/fs/hfs/dir.c
@@ -196,8 +196,8 @@ static int hfs_create(struct mnt_idmap *idmap, struct inode *dir,
 	int res;
 
 	inode = hfs_new_inode(dir, &dentry->d_name, mode);
-	if (!inode)
-		return -ENOMEM;
+	if (IS_ERR(inode))
+		return PTR_ERR(inode);
 
 	res = hfs_cat_create(inode->i_ino, dir, &dentry->d_name, inode);
 	if (res) {
@@ -226,8 +226,8 @@ static struct dentry *hfs_mkdir(struct mnt_idmap *idmap, struct inode *dir,
 	int res;
 
 	inode = hfs_new_inode(dir, &dentry->d_name, S_IFDIR | mode);
-	if (!inode)
-		return ERR_PTR(-ENOMEM);
+	if (IS_ERR(inode))
+		return ERR_CAST(inode);
 
 	res = hfs_cat_create(inode->i_ino, dir, &dentry->d_name, inode);
 	if (res) {
diff --git a/fs/hfs/inode.c b/fs/hfs/inode.c
index 9cd449913dc8..beec6fe7e801 100644
--- a/fs/hfs/inode.c
+++ b/fs/hfs/inode.c
@@ -186,16 +186,23 @@ struct inode *hfs_new_inode(struct inode *dir, const struct qstr *name, umode_t
 	s64 next_id;
 	s64 file_count;
 	s64 folder_count;
+	int err = -ENOMEM;
 
 	if (!inode)
-		return NULL;
+		goto out_err;
+
+	err = -ENOSPC;
 
 	mutex_init(&HFS_I(inode)->extents_lock);
 	INIT_LIST_HEAD(&HFS_I(inode)->open_dir_list);
 	spin_lock_init(&HFS_I(inode)->open_dir_lock);
 	hfs_cat_build_key(sb, (btree_key *)&HFS_I(inode)->cat_key, dir->i_ino, name);
 	next_id = atomic64_inc_return(&HFS_SB(sb)->next_id);
-	BUG_ON(next_id > U32_MAX);
+	if (next_id > U32_MAX) {
+		pr_err("hfs: next file ID exceeds 32-bit limit — possible "
+		       "superblock corruption");
+		goto out_discard;
+	}
 	inode->i_ino = (u32)next_id;
 	inode->i_mode = mode;
 	inode->i_uid = current_fsuid();
@@ -209,7 +216,11 @@ struct inode *hfs_new_inode(struct inode *dir, const struct qstr *name, umode_t
 	if (S_ISDIR(mode)) {
 		inode->i_size = 2;
 		folder_count = atomic64_inc_return(&HFS_SB(sb)->folder_count);
-		BUG_ON(folder_count > U32_MAX);
+		if (folder_count > U32_MAX) {
+			pr_err("hfs: folder count exceeds 32-bit limit — possible "
+			       "superblock corruption");
+			goto out_discard;
+		}
 		if (dir->i_ino == HFS_ROOT_CNID)
 			HFS_SB(sb)->root_dirs++;
 		inode->i_op = &hfs_dir_inode_operations;
@@ -219,7 +230,11 @@ struct inode *hfs_new_inode(struct inode *dir, const struct qstr *name, umode_t
 	} else if (S_ISREG(mode)) {
 		HFS_I(inode)->clump_blocks = HFS_SB(sb)->clumpablks;
 		file_count = atomic64_inc_return(&HFS_SB(sb)->file_count);
-		BUG_ON(file_count > U32_MAX);
+		if (file_count > U32_MAX) {
+			pr_err("hfs: file count exceeds 32-bit limit — possible "
+			       "superblock corruption");
+			goto out_discard;
+		}
 		if (dir->i_ino == HFS_ROOT_CNID)
 			HFS_SB(sb)->root_files++;
 		inode->i_op = &hfs_file_inode_operations;
@@ -243,6 +258,11 @@ struct inode *hfs_new_inode(struct inode *dir, const struct qstr *name, umode_t
 	hfs_mark_mdb_dirty(sb);
 
 	return inode;
+
+	out_discard:
+		iput(inode);	
+	out_err:
+		return ERR_PTR(err); 
 }
 
 void hfs_delete_inode(struct inode *inode)
@@ -251,7 +271,6 @@ void hfs_delete_inode(struct inode *inode)
 
 	hfs_dbg("ino %lu\n", inode->i_ino);
 	if (S_ISDIR(inode->i_mode)) {
-		BUG_ON(atomic64_read(&HFS_SB(sb)->folder_count) > U32_MAX);
 		atomic64_dec(&HFS_SB(sb)->folder_count);
 		if (HFS_I(inode)->cat_key.ParID == cpu_to_be32(HFS_ROOT_CNID))
 			HFS_SB(sb)->root_dirs--;
@@ -260,7 +279,6 @@ void hfs_delete_inode(struct inode *inode)
 		return;
 	}
 
-	BUG_ON(atomic64_read(&HFS_SB(sb)->file_count) > U32_MAX);
 	atomic64_dec(&HFS_SB(sb)->file_count);
 	if (HFS_I(inode)->cat_key.ParID == cpu_to_be32(HFS_ROOT_CNID))
 		HFS_SB(sb)->root_files--;
diff --git a/fs/hfs/mdb.c b/fs/hfs/mdb.c
index 53f3fae60217..1c3fb631cc8e 100644
--- a/fs/hfs/mdb.c
+++ b/fs/hfs/mdb.c
@@ -273,15 +273,12 @@ void hfs_mdb_commit(struct super_block *sb)
 		/* These parameters may have been modified, so write them back */
 		mdb->drLsMod = hfs_mtime();
 		mdb->drFreeBks = cpu_to_be16(HFS_SB(sb)->free_ablocks);
-		BUG_ON(atomic64_read(&HFS_SB(sb)->next_id) > U32_MAX);
 		mdb->drNxtCNID =
 			cpu_to_be32((u32)atomic64_read(&HFS_SB(sb)->next_id));
 		mdb->drNmFls = cpu_to_be16(HFS_SB(sb)->root_files);
 		mdb->drNmRtDirs = cpu_to_be16(HFS_SB(sb)->root_dirs);
-		BUG_ON(atomic64_read(&HFS_SB(sb)->file_count) > U32_MAX);
 		mdb->drFilCnt =
 			cpu_to_be32((u32)atomic64_read(&HFS_SB(sb)->file_count));
-		BUG_ON(atomic64_read(&HFS_SB(sb)->folder_count) > U32_MAX);
 		mdb->drDirCnt =
 			cpu_to_be32((u32)atomic64_read(&HFS_SB(sb)->folder_count));
 
-- 
2.51.1.dirty

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: jkoolstra@xs4all.nl

#syz dup: WARNING in ntfs_put_super

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: eslam.medhat1993@gmail.com

#syz test

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: eslam.medhat1993@gmail.com

#syz test

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: eslam.medhat1993@gmail.com

#syz test

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: eslam.medhat1993@gmail.com

#syz test

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: eslam.medhat1993@gmail.com

#syz test

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: eslam.medhat1993@gmail.com

#syz test

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org.

***

Subject: 
Author: jkoolstra@xs4all.nl

#syz test

---
 fs/minix/inode.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/fs/minix/inode.c b/fs/minix/inode.c
index 7897f5123b3d..bee191c50010 100644
--- a/fs/minix/inode.c
+++ b/fs/minix/inode.c
@@ -171,7 +171,15 @@ static bool minix_check_superblock(struct super_block *sb)
 {
 	struct minix_sb_info *sbi = minix_sb(sb);
 
-	if (sbi->s_imap_blocks == 0 || sbi->s_zmap_blocks == 0)
+	if (sbi->s_log_zone_size != 0) {
+		printk("minix-fs error: zone size must equal block size. "
+		       "s_log_zone_size > 0 is not supported.\n");
+		return false;
+	}
+
+	if (sbi->s_imap_blocks < 1 || sbi->s_zmap_blocks < 1 ||
+	    sbi->s_ninodes < 1 || sbi->s_firstdatazone <= 4 ||
+	    sbi->s_firstdatazone >= sbi->s_nzones)
 		return false;
 
 	/*
-- 
2.51.2

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: agruenba@redhat.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2.git
4daba9379bbd702c63459f54ef448746bfeab42d

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: pimyn@google.com

#syz invalid

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: contact@gvernon.com

#syz test

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: klnm1908v@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master

diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c
index 91fd3673c09a..e588a188f50a 100644
--- a/arch/x86/kvm/xen.c
+++ b/arch/x86/kvm/xen.c
@@ -126,23 +126,10 @@ static enum hrtimer_restart
xen_timer_callback(struct hrtimer *timer)
 {
 	struct kvm_vcpu *vcpu = container_of(timer, struct kvm_vcpu,
 					     arch.xen.timer);
-	struct kvm_xen_evtchn e;
-	int rc;

 	if (atomic_read(&vcpu->arch.xen.timer_pending))
 		return HRTIMER_NORESTART;

-	e.vcpu_id = vcpu->vcpu_id;
-	e.vcpu_idx = vcpu->vcpu_idx;
-	e.port = vcpu->arch.xen.timer_virq;
-	e.priority = KVM_IRQ_ROUTING_XEN_EVTCHN_PRIO_2LEVEL;
-
-	rc = kvm_xen_set_evtchn_fast(&e, vcpu->kvm);
-	if (rc != -EWOULDBLOCK) {
-		vcpu->arch.xen.timer_expires = 0;
-		return HRTIMER_NORESTART;
-	}
-
 	atomic_inc(&vcpu->arch.xen.timer_pending);
 	kvm_make_request(KVM_REQ_UNBLOCK, vcpu);
 	kvm_vcpu_kick(vcpu);

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: halves@igalia.com

#syz test

--- a/drivers/media/dvb-core/dvbdev.c
+++ b/drivers/media/dvb-core/dvbdev.c
@@ -147,6 +147,7 @@ int dvb_generic_open(struct inode *inode, struct file *file)
                dvbdev->writers--;
        }

+       dvb_device_get(dvbdev);
        dvbdev->users--;
        return 0;
 }
-- 
2.53.0

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: daiky0325@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: nogikh@google.com

The bug is actually fixed long time ago.

#syz invalid

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: nogikh@google.com

#syz invalid

The bug is actually no longer present.

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: nogikh@google.com

The bug has actually been already fixed.

#syz invalid

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: nogikh@google.com

#syz invalid

Doesn't happen for a long time in fact.

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: nogikh@google.com

#syz invalid

Actually fixed long ago.

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: nogikh@google.com

#syz invalid

Fixed long ago

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: nogikh@google.com

#syz invalid

Actually already fixed

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: nogikh@google.com

#syz invalid

It hasn't been happening in a very long time.

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: nogikh@google.com

#syz invalid

hasn't happened in a while

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: nogikh@google.com

Hasn't been happening in a long while.

#syz invalid

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: nogikh@google.com

Apparently, already fixed.

#syz invalid

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: nogikh@google.com

Let's check if the command works.

#syz test

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: joshua.crofts1@gmail.com

#syz test

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: joshua.crofts1@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
58717b2a1365

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: nogikh@google.com

#syz invalid

Hasn't happened for a long while

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: nogikh@google.com

#syz invalid

Hasn't happened in a long while

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: nogikh@google.com

#syz invalid

Hasn't happened in a long while

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: nogikh@google.com

#syz invalid

Hasn't happened in a long while.

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: nogikh@google.com

#syz invalid

Shouldn't be there

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: nogikh@google.com

#syz invalid

Hasn't happened in a while

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: joshua.crofts1@gmail.com

#syz test

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org.

***

Subject: 
Author: jeffinphilip14@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
51cb1aa1250c36269474b8b6ca6b6319e170f5a5

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: joshua.crofts1@gmail.com

#syz test

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: joshua.crofts1@gmail.com

#syz test

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: joshua.crofts1@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: nogikh@google.com

#syz dup: general protection fault in dummy_udc_start

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: joshua.crofts1@gmail.com

#syz test

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: joshua.crofts1@gmail.com

#syz test

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: nogikh@google.com

#syz invalid

Hasn't happened for a while

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: joshua.crofts1@gmail.com

#syz test

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: joshua.crofts1@gmail.com

#syz test

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: nogikh@google.com

#syz invalid

Forwarded:

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: 
Author: nogikh@google.com

#syz invalid