[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+8d2757...@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 syzk...@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

[Edward AD]

please test stack-out-of-bounds Read in sched_show_task

#syz test git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes

diff --git a/arch/riscv/kernel/stacktrace.c b/arch/riscv/kernel/stacktrace.c
index 64a9c093aef9..399e439f8bef 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 (unlikely(frame < low || frame > high))
+ break;
sp = fp;
if (regs && (regs->epc == pc) && (frame->fp & 0x7)) {
fp = frame->ra;

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
KASAN: out-of-bounds Read in kernel_clone

Workqueue: events_power_efficient wg_ratelimiter_gc_entries
Call Trace:
[<ffffffff8360b8bc>] context_switch kernel/sched/core.c:5382 [inline]
[<ffffffff8360b8bc>] __schedule+0x794/0x1884 kernel/sched/core.c:6695
==================================================================
BUG: KASAN: out-of-bounds in walk_stackframe+0x130/0x2fc arch/riscv/kernel/stacktrace.c:60
Read of size 8 at addr ff20000002957b70 by task kworker/u5:0/2980

CPU: 0 PID: 2980 Comm: kworker/u5:0 Not tainted 6.6.0-rc1-syzkaller-gb06fab003ae1-dirty #0
Hardware name: riscv-virtio,qemu (DT)
Workqueue: events_unbound call_usermodehelper_exec_work
Call Trace:
[<ffffffff8000b970>] dump_backtrace+0x2e/0x3c arch/riscv/kernel/stacktrace.c:123
[<ffffffff835c3868>] show_stack+0x34/0x40 arch/riscv/kernel/stacktrace.c:129
[<ffffffff836036b6>] __dump_stack lib/dump_stack.c:88 [inline]
[<ffffffff836036b6>] dump_stack_lvl+0xe8/0x154 lib/dump_stack.c:106
[<ffffffff835cbf30>] print_address_description mm/kasan/report.c:364 [inline]
[<ffffffff835cbf30>] print_report+0x1e4/0x4f4 mm/kasan/report.c:475
[<ffffffff8057aa6e>] kasan_report+0xf0/0x1ba mm/kasan/report.c:588
[<ffffffff8057bd8a>] check_region_inline mm/kasan/generic.c:181 [inline]
[<ffffffff8057bd8a>] __asan_load8+0x80/0xa8 mm/kasan/generic.c:260

The buggy address belongs to the virtual mapping at

[ff20000002950000, ff20000002959000) created by:

kernel_clone+0x118/0x896 kernel/fork.c:2909

The buggy address belongs to the physical page:

page:ff1c0000024f6200 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x93d88

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 0x102dc2(GFP_HIGHUSER|__GFP_NOWARN|__GFP_ZERO), pid 1050, tgid 1050 (kworker/u6:6), ts 774352086000, free_ts 770944568300

ff20000002957a00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ff20000002957a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ff20000002957b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
^
ff20000002957b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ff20000002957c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================


Tested on:

commit: b06fab00 riscv: kselftests: Fix mm build by removing t..

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=150fcb86680000

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

patch: https://syzkaller.appspot.com/x/patch.diff?x=11c9cc4c680000

[Edward AD]

please test stack-out-of-bounds Read in sched_show_task

#syz test git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes

diff --git a/arch/riscv/kernel/stacktrace.c b/arch/riscv/kernel/stacktrace.c

index 64a9c093aef9..5eb2a204c05b 100644
--- a/arch/riscv/kernel/stacktrace.c
+++ b/arch/riscv/kernel/stacktrace.c
@@ -23,6 +23,7 @@ void notrace walk_stackframe(struct task_struct *task, struct pt_regs *regs,
{
unsigned long fp, sp, pc;
int level = 0;
+ int s = sizeof(struct stackframe);

if (regs) {
fp = frame_pointer(regs);
@@ -50,7 +51,7 @@ void notrace walk_stackframe(struct task_struct *task, struct pt_regs *regs,
/* Validate frame pointer */
low = sp + sizeof(struct stackframe);
high = ALIGN(sp, THREAD_SIZE);
- if (unlikely(fp < low || fp > high || fp & 0x7))
+ if (unlikely(fp < low + s || fp > high - s || fp & 0x7))

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
KASAN: out-of-bounds Read in kernel_clone

task:kworker/0:3 state:R running task stack:0 pid:3875 ppid:2 flags:0x00000000

Workqueue: events_power_efficient wg_ratelimiter_gc_entries
Call Trace:

[<ffffffff8360b8ac>] context_switch kernel/sched/core.c:5382 [inline]
[<ffffffff8360b8ac>] __schedule+0x794/0x1884 kernel/sched/core.c:6695
==================================================================
BUG: KASAN: out-of-bounds in walk_stackframe+0x120/0x2ea arch/riscv/kernel/stacktrace.c:59
Read of size 8 at addr ff20000002a57b70 by task kworker/1:4/3815

CPU: 1 PID: 3815 Comm: kworker/1:4 Not tainted 6.6.0-rc1-syzkaller-gb06fab003ae1-dirty #0
Hardware name: riscv-virtio,qemu (DT)
Workqueue: usb_hub_wq hub_event
Call Trace:
[<ffffffff8000b95e>] dump_backtrace+0x2e/0x3c arch/riscv/kernel/stacktrace.c:122
[<ffffffff835c3858>] show_stack+0x34/0x40 arch/riscv/kernel/stacktrace.c:128
[<ffffffff836036a6>] __dump_stack lib/dump_stack.c:88 [inline]
[<ffffffff836036a6>] dump_stack_lvl+0xe8/0x154 lib/dump_stack.c:106
[<ffffffff835cbf20>] print_address_description mm/kasan/report.c:364 [inline]
[<ffffffff835cbf20>] print_report+0x1e4/0x4f4 mm/kasan/report.c:475
[<ffffffff8057aa5e>] kasan_report+0xf0/0x1ba mm/kasan/report.c:588
[<ffffffff8057bd7a>] check_region_inline mm/kasan/generic.c:181 [inline]
[<ffffffff8057bd7a>] __asan_load8+0x80/0xa8 mm/kasan/generic.c:260

The buggy address belongs to the virtual mapping at

[ff20000002a50000, ff20000002a59000) created by:

kernel_clone+0x118/0x896 kernel/fork.c:2909

The buggy address belongs to the physical page:

page:ff1c0000024f3040 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x93cc1

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 0x102dc2(GFP_HIGHUSER|__GFP_NOWARN|__GFP_ZERO), pid 2, tgid 2 (kthreadd), ts 892887995600, free_ts 527260666700

__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_node include/linux/gfp.h:237 [inline]
alloc_pages_node include/linux/gfp.h:260 [inline]
vm_area_alloc_pages mm/vmalloc.c:3065 [inline]
__vmalloc_area_node mm/vmalloc.c:3139 [inline]
__vmalloc_node_range+0x516/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

kernel_thread+0xf4/0x126 kernel/fork.c:2971
create_kthread kernel/kthread.c:411 [inline]
kthreadd+0x33e/0x482 kernel/kthread.c:746

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

free_pages.part.0+0xd8/0x136 mm/page_alloc.c:4527
free_pages+0xe/0x18 mm/page_alloc.c:4524

Memory state around the buggy address:

ff20000002a57a00: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 f1 f1 04 f2
ff20000002a57a80: 00 00 f2 f2 00 00 00 f3 f3 f3 f3 f3 00 00 00 00
>ff20000002a57b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
^
ff20000002a57b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ff20000002a57c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

==================================================================


Tested on:

commit: b06fab00 riscv: kselftests: Fix mm build by removing t..
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=163cf78c680000

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

patch: https://syzkaller.appspot.com/x/patch.diff?x=12fdaae2680000

[ead...@sina.com]

From: Edward AD <eda...@sina.com>

please test stack-out-of-bounds Read in sched_show_task

#syz test git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes

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

[syzbot]

Hello,

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

Reported-and-tested-by: syzbot+8d2757...@syzkaller.appspotmail.com

Tested on:

commit: 9f564b92 riscv: Only consider swbp/ss handlers for cor..

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=11be73ac680000

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

patch: https://syzkaller.appspot.com/x/patch.diff?x=110402f2680000

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

[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+8d2757...@syzkaller.appspotmail.com
Signed-off-by: Edward AD <twuu...@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

[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.10...@gmail.com/
Fixes: 5d8544e2d007 ("RISC-V: Generic library routines and assembly")
Reported-and-tested-by: syzbot+8d2757...@syzkaller.appspotmail.com
Link: https://lore.kernel.org/all/00000000000001...@google.com/T/

[Greg KH]

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

[Alexandre Ghiti]

Hi Edward,

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

[Alexandre Ghiti]

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

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

[Conor Dooley]

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+8d2757...@syzkaller.appspotmail.com

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

Thanks,
Conor.

[Edward AD]

please test stack-out-of-bounds Read in sched_show_task

#syz test git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes

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 (!access_ok(frame, sizeof(struct stackframe)))

[syzbot]

Hello,

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

Reported-and-tested-by: syzbot+8d2757...@syzkaller.appspotmail.com

Tested on:

commit: 9f564b92 riscv: Only consider swbp/ss handlers for cor..
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=11b88dfa680000

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

patch: https://syzkaller.appspot.com/x/patch.diff?x=1025fe12680000

[Edward AD]

please test stack-out-of-bounds Read in sched_show_task

#syz test git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes

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

[Edward AD]

please test stack-out-of-bounds Read in sched_show_task

#syz test git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes

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

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:

KASAN: out-of-bounds Read in sched_show_task

[<ffffffff8360bc8c>] context_switch kernel/sched/core.c:5382 [inline]
[<ffffffff8360bc8c>] __schedule+0x794/0x1884 kernel/sched/core.c:6695
[<ffffffff8360cdf4>] schedule+0x78/0xfe kernel/sched/core.c:6771
[<ffffffff83617f8e>] do_nanosleep+0x18a/0x318 kernel/time/hrtimer.c:2047
==================================================================
BUG: KASAN: out-of-bounds in walk_stackframe+0x18c/0x6cc arch/riscv/kernel/stacktrace.c:62
Read of size 8 at addr ff20000001967c38 by task kworker/0:4/3277

CPU: 0 PID: 3277 Comm: kworker/0:4 Not tainted 6.6.0-rc1-syzkaller-g9f564b92cf6d-dirty #0

Hardware name: riscv-virtio,qemu (DT)
Workqueue: usb_hub_wq hub_event
Call Trace:

[<ffffffff8000bd40>] dump_backtrace+0x2e/0x3c arch/riscv/kernel/stacktrace.c:124
[<ffffffff835c3c38>] show_stack+0x34/0x40 arch/riscv/kernel/stacktrace.c:130
[<ffffffff83603a86>] __dump_stack lib/dump_stack.c:88 [inline]
[<ffffffff83603a86>] dump_stack_lvl+0xe8/0x154 lib/dump_stack.c:106
[<ffffffff835cc300>] print_address_description mm/kasan/report.c:364 [inline]
[<ffffffff835cc300>] print_report+0x1e4/0x4f4 mm/kasan/report.c:475
[<ffffffff8057ae3e>] kasan_report+0xf0/0x1ba mm/kasan/report.c:588
[<ffffffff8057c15a>] check_region_inline mm/kasan/generic.c:181 [inline]
[<ffffffff8057c15a>] __asan_load8+0x80/0xa8 mm/kasan/generic.c:260
[<ffffffff8000b7d2>] walk_stackframe+0x18c/0x6cc arch/riscv/kernel/stacktrace.c:62
[<ffffffff8000bd40>] dump_backtrace+0x2e/0x3c arch/riscv/kernel/stacktrace.c:124
[<ffffffff835c3c38>] show_stack+0x34/0x40 arch/riscv/kernel/stacktrace.c:130
[<ffffffff800f6622>] sched_show_task kernel/sched/core.c:9182 [inline]
[<ffffffff800f6622>] sched_show_task+0x2ee/0x414 kernel/sched/core.c:9156
[<ffffffff801011da>] show_state_filter+0xa0/0x1e0 kernel/sched/core.c:9227
[<ffffffff80fa1056>] show_state include/linux/sched/debug.h:21 [inline]
[<ffffffff80fa1056>] fn_show_state+0x1a/0x22 drivers/tty/vt/keyboard.c:614
[<ffffffff80fa152a>] k_spec drivers/tty/vt/keyboard.c:667 [inline]
[<ffffffff80fa152a>] k_spec+0xce/0x102 drivers/tty/vt/keyboard.c:656
[<ffffffff80fa3444>] kbd_keycode drivers/tty/vt/keyboard.c:1524 [inline]
[<ffffffff80fa3444>] kbd_event+0x5fa/0xa5e drivers/tty/vt/keyboard.c:1543
[<ffffffff82138892>] input_to_handler+0x246/0x24c drivers/input/input.c:132
[<ffffffff8213d6e8>] input_pass_values+0x410/0x5fe drivers/input/input.c:161
[<ffffffff8213db8e>] input_event_dispose+0x2b8/0x2c8 drivers/input/input.c:389
[<ffffffff8213f930>] input_handle_event+0xf0/0x972 drivers/input/input.c:406
[<ffffffff8214023c>] input_event drivers/input/input.c:435 [inline]
[<ffffffff8214023c>] input_event+0x8a/0xb2 drivers/input/input.c:427
[<ffffffff82681466>] hidinput_hid_event+0x54e/0x1438 drivers/hid/hid-input.c:1729
[<ffffffff826723f0>] hid_process_event+0x348/0x38a drivers/hid/hid-core.c:1534
[<ffffffff8267277a>] hid_input_array_field+0x348/0x404 drivers/hid/hid-core.c:1646
[<ffffffff82672f7a>] hid_process_report drivers/hid/hid-core.c:1688 [inline]
[<ffffffff82672f7a>] hid_report_raw_event+0x744/0xa5c drivers/hid/hid-core.c:2009
[<ffffffff826734e0>] hid_input_report+0x24e/0x2f4 drivers/hid/hid-core.c:2083
[<ffffffff8273895c>] hid_irq_in+0x244/0x412 drivers/hid/usbhid/hid-core.c:284
[<ffffffff81d6a872>] __usb_hcd_giveback_urb+0x222/0x364 drivers/usb/core/hcd.c:1650
[<ffffffff81d6ac2e>] usb_hcd_giveback_urb+0x27a/0x290 drivers/usb/core/hcd.c:1733
[<ffffffff82027eec>] dummy_timer+0xfc2/0x204a drivers/usb/gadget/udc/dummy_hcd.c:1987
[<ffffffff801d46aa>] call_timer_fn+0x15a/0x4f2 kernel/time/timer.c:1700
[<ffffffff801d4fc0>] expire_timers kernel/time/timer.c:1751 [inline]
[<ffffffff801d4fc0>] __run_timers+0x57e/0x73c kernel/time/timer.c:2022
[<ffffffff801d51c4>] run_timer_softirq+0x46/0x80 kernel/time/timer.c:2035
[<ffffffff83619a0a>] __do_softirq+0x2ee/0x8a2 kernel/softirq.c:553
[<ffffffff8008b328>] invoke_softirq kernel/softirq.c:427 [inline]
[<ffffffff8008b328>] __irq_exit_rcu+0xfa/0x1b0 kernel/softirq.c:632
[<ffffffff8008b5be>] irq_exit_rcu+0x10/0x72 kernel/softirq.c:644
[<ffffffff836048d2>] handle_riscv_irq+0x40/0x4c arch/riscv/kernel/traps.c:357
[<ffffffff83604f86>] do_irq+0x5c/0x86 arch/riscv/kernel/traps.c:367

The buggy address belongs to the virtual mapping at

[ff20000001960000, ff20000001969000) created by:

kernel_clone+0x118/0x896 kernel/fork.c:2909

The buggy address belongs to the physical page:

page:ff1c000002512600 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x94498

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 0x102dc2(GFP_HIGHUSER|__GFP_NOWARN|__GFP_ZERO), pid 3467, tgid 3467 (syz-executor.0), ts 1092293184900, free_ts 1091366212100

__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

__do_sys_clone+0xe4/0x118 kernel/fork.c:3052
__se_sys_clone kernel/fork.c:3020 [inline]
__riscv_sys_clone+0x76/0x88 kernel/fork.c:3020
syscall_handler+0x76/0xba arch/riscv/include/asm/syscall.h:90
do_trap_ecall_u+0x9c/0x9e arch/riscv/kernel/traps.c:320
ret_from_exception+0x0/0x64 arch/riscv/kernel/entry.S:102

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

__free_slab+0xbc/0x112 mm/slub.c:2087
free_slab+0x38/0x190 mm/slub.c:2110
discard_slab mm/slub.c:2116 [inline]
__unfreeze_partials+0x1c0/0x1f8 mm/slub.c:2655
put_cpu_partial+0x158/0x220 mm/slub.c:2731
__slab_free+0x20c/0x2de mm/slub.c:3679
do_slab_free mm/slub.c:3757 [inline]
___cache_free+0x136/0x154 mm/slub.c:3816
qlink_free mm/kasan/quarantine.c:166 [inline]
qlist_free_all+0x7a/0x16c mm/kasan/quarantine.c:185
kasan_quarantine_reduce+0x158/0x1ba mm/kasan/quarantine.c:292
__kasan_slab_alloc+0x5e/0x84 mm/kasan/common.c:305
kasan_slab_alloc include/linux/kasan.h:188 [inline]
slab_post_alloc_hook mm/slab.h:762 [inline]
slab_alloc_node mm/slub.c:3478 [inline]
__kmem_cache_alloc_node+0x124/0x2e0 mm/slub.c:3517
kmalloc_trace+0x24/0x56 mm/slab_common.c:1114
kmalloc include/linux/slab.h:599 [inline]
syslog_print+0x120/0x5de kernel/printk/printk.c:1553

Memory state around the buggy address:

ff20000001967b00: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
ff20000001967b80: 00 00 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
>ff20000001967c00: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
^
ff20000001967c80: f1 f1 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3
ff20000001967d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================

Tested on:

commit: 9f564b92 riscv: Only consider swbp/ss handlers for cor..
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=1682ee32680000

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

patch: https://syzkaller.appspot.com/x/patch.diff?x=1301e3bc680000

[syzbot]

Hello,

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

Reported-and-tested-by: syzbot+8d2757...@syzkaller.appspotmail.com

Tested on:

commit: 9f564b92 riscv: Only consider swbp/ss handlers for cor..
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=13a6268e680000

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

patch: https://syzkaller.appspot.com/x/patch.diff?x=12459f12680000

[Edward AD]

Add vmalloc and kernel addresses check to prevent invalid access.

Closes: https://lore.kernel.org/all/20230926105949.10...@gmail.com/
Fixes: 5d8544e2d007 ("RISC-V: Generic library routines and assembly")

Reported-and-test-by: syzbot+8d2757...@syzkaller.appspotmail.com

Link: https://lore.kernel.org/all/00000000000001...@google.com/T/
Signed-off-by: Edward AD <twuu...@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

[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.10...@gmail.com/
> Fixes: 5d8544e2d007 ("RISC-V: Generic library routines and assembly")
> Reported-and-test-by: syzbot+8d2757...@syzkaller.appspotmail.com
> Link: https://lore.kernel.org/all/00000000000001...@google.com/T/
> Signed-off-by: Edward AD <twuu...@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

[Greg KH]

On Fri, Sep 29, 2023 at 07:12:40AM +0800, Edward AD wrote:

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.

[Alexandre Ghiti]

Hi Edward,

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

[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/00000000000001...@google.com/raw

Thanks,
edward

[Edward AD]

Hi Alexandre,

On Fri, 29 Sep 2023 10:25:59 +0200 Alexandre Ghiti <alex...@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

[Greg KH]

I do not understand this answer.

[Conor Dooley]

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

[Alexandre Ghiti]

Hi Edward,

On Sat, Sep 30, 2023 at 1:06 AM Edward AD <twuu...@gmail.com> wrote:
>
> Hi Alexandre,
>
> On Fri, 29 Sep 2023 10:25:59 +0200 Alexandre Ghiti <alex...@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.

[Aleksandr Nogikh]

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

[Mark Rutland]

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.

[Alexandre Ghiti]

Hi Mark,

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.