Re: [syzbot] [arm?] BUG: unable to handle kernel paging request in task_h_load

From: Will Deacon
Date: Tue Jun 04 2024 - 07:01:31 EST


Hello Syzbot,

On Tue, May 28, 2024 at 05:47:22AM -0700, syzbot wrote:
> syzbot found the following issue on:
>
> HEAD commit: 6d69b6c12fce Merge tag 'nfs-for-6.10-1' of git://git.linux..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=164ce7f0980000
> kernel config: https://syzkaller.appspot.com/x/.config?x=21de3d423116c304
> dashboard link: https://syzkaller.appspot.com/bug?extid=8336c747d79a4c3a0944
> compiler: aarch64-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
> userspace arch: arm64
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=119fbe58980000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13a8443c980000
>
> Downloadable assets:
> disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/384ffdcca292/non_bootable_disk-6d69b6c1.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/9fa4d7c3665d/vmlinux-6d69b6c1.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/131ac291917c/Image-6d69b6c1.gz.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+8336c747d79a4c3a0944@xxxxxxxxxxxxxxxxxxxxxxxxx
>
> Unable to handle kernel paging request at virtual address 007000000621a118
> Mem abort info:
> ESR = 0x0000000096000004
> EC = 0x25: DABT (current EL), IL = 32 bits
> SET = 0, FnV = 0
> EA = 0, S1PTW = 0
> FSC = 0x04: level 0 translation fault
> Data abort info:
> ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
> CM = 0, WnR = 0, TnD = 0, TagAccess = 0
> GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> [007000000621a118] address between user and kernel address ranges
> Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
> Modules linked in:
> CPU: 1 PID: 3189 Comm: syz-executor371 Not tainted 6.9.0-syzkaller-12124-g6d69b6c12fce #0
> Hardware name: linux,dummy-virt (DT)
> pstate: 204000c9 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> pc : cfs_rq_of kernel/sched/sched.h:1468 [inline]
> pc : update_cfs_rq_h_load kernel/sched/fair.c:9441 [inline]
> pc : task_h_load+0x40/0xb8 kernel/sched/fair.c:9466
> lr : detach_tasks kernel/sched/fair.c:9181 [inline]
> lr : sched_balance_rq+0x80c/0xc94 kernel/sched/fair.c:11375

Mark and I were looking at this today and we believe it should be fixed
by:

https://lore.kernel.org/all/20240524005444.135417-1-21cnbao@xxxxxxxxx/T/#u

which is queued in -next via the mm tree and will hopefully land in -rc3.

Will