Re: [syzbot] [kernel?] Internal error in futex_wake_op

[Will Deacon]

On Fri, Sep 04, 2026 at 07:40:42AM +0200, Thomas Gleixner wrote:
> On Thu, Aug 27 2026 at 11:52, syzbot wrote:
> 
> CC+: ARM64 people...
> 
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:    68f892e99df9 Merge branch 'for-next/core' into for-kernelci
> > git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci
> > console output: https://syzkaller.appspot.com/x/log.txt?x=13dc7415580000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=d1128bc53f2ef7f3
> > dashboard link: https://syzkaller.appspot.com/bug?extid=417a6b7c02d5d03f9aa6
> > compiler:       Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
> > userspace arch: arm64
> > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1512d625580000
> > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=13e2859e580000
> >
> > Downloadable assets:
> > disk image: https://storage.googleapis.com/syzbot-assets/f98dd20a7b98/disk-68f892e9.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/441f1ad32549/vmlinux-68f892e9.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/8da5227b7dc8/Image-68f892e9.gz.xz
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+417a6b7c02d5d03f9aa6@xxxxxxxxxxxxxxxxxxxxxxxxx
> >
> > futex_wake_op: syz.0.17 tries to shift op by 144; fix this program
> > Internal error: synchronous external abort: 0000000096000010 [#1]  SMP

This is an _external_ abort!

> > Modules linked in:
> > CPU: 0 UID: 0 PID: 4917 Comm: syz.0.17 Tainted: G   M                syzkaller #0 PREEMPT 
> > Tainted: [M]=MACHINE_CHECK
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/07/2026
> > pstate: 83000005 (Nzcv daif -PAN -UAO +TCO +DIT -SSBS BTYPE=--)
> > pc : __llsc_futex_atomic_or arch/arm64/include/asm/futex.h:51 [inline]
> > pc : __futex_atomic_or arch/arm64/include/asm/futex.h:239 [inline]
> > pc : arch_futex_atomic_op_inuser arch/arm64/include/asm/futex.h:269 [inline]
> > pc : futex_atomic_op_inuser kernel/futex/waitwake.c:251 [inline]
> > pc : futex_wake_op+0x450/0xfe8 kernel/futex/waitwake.c:302
> > lr : mte_enable_tco arch/arm64/include/asm/mte-kasan.h:62 [inline]
> > lr : uaccess_enable_privileged arch/arm64/include/asm/uaccess.h:147 [inline]
> > lr : __llsc_futex_atomic_or arch/arm64/include/asm/futex.h:51 [inline]
> > lr : __futex_atomic_or arch/arm64/include/asm/futex.h:239 [inline]
> > lr : arch_futex_atomic_op_inuser arch/arm64/include/asm/futex.h:269 [inline]
> > lr : futex_atomic_op_inuser kernel/futex/waitwake.c:251 [inline]
> > lr : futex_wake_op+0x43c/0xfe8 kernel/futex/waitwake.c:302
> > sp : ffff800093197980
> > x29: ffff800093197b40 x28: 0000000000010000 x27: 0000000000000000
> > x26: 1fffe00018d2a3ad x25: dfff800000000000 x24: ffff0000c6951d40
> > x23: ffff0000c6951d6c x22: 0000000000000002 x21: 1fffe00018d2a685
> > x20: ffff0000c1df3780 x19: ffff0000c695342c x18: 0000000000000000
> > x17: 72676f7270207369 x16: 687420786966203b x15: 3434312079622070
> > x14: 6f20746669687320 x13: 0000000000000001 x12: 0000000000000000
> > x11: 0000000000000000 x10: 00000000fffffff5 x9 : 0000000000000000

X11 is NULL...

> > x8 : 0000000000000080 x7 : ffff80008048c60c x6 : 0000000000000000
> > x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff8000805b0678
> > x2 : 0000000000000002 x1 : ffff0000c6951d40 x0 : 0000000000000000
> > Call trace:
> >  __llsc_futex_atomic_or arch/arm64/include/asm/futex.h:51 [inline] (P)
> >  __futex_atomic_or arch/arm64/include/asm/futex.h:239 [inline] (P)
> >  arch_futex_atomic_op_inuser arch/arm64/include/asm/futex.h:269 [inline] (P)
> >  futex_atomic_op_inuser kernel/futex/waitwake.c:251 [inline] (P)
> >  futex_wake_op+0x450/0xfe8 kernel/futex/waitwake.c:302 (P)
> >  do_futex+0x200/0x378 kernel/futex/syscalls.c:144
> >  __do_sys_futex kernel/futex/syscalls.c:210 [inline]
> >  __se_sys_futex kernel/futex/syscalls.c:191 [inline]
> >  __arm64_sys_futex+0x2e4/0x418 kernel/futex/syscalls.c:191
> >  __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
> >  invoke_syscall+0x98/0x244 arch/arm64/kernel/syscall.c:49
> >  el0_svc_common+0xec/0x23c arch/arm64/kernel/syscall.c:121
> >  do_el0_svc+0x4c/0x5c arch/arm64/kernel/syscall.c:140
> >  el0_svc+0x64/0x260 arch/arm64/kernel/entry-common.c:758
> >  el0t_64_sync_handler+0x44/0x104 arch/arm64/kernel/entry-common.c:777
> >  el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:590
> > Code: d500409f 1280014a f94057eb f9800171 (885f7d76) 
> > ---[ end trace 0000000000000000 ]---
> > ----------------
> > Code disassembly (best guess):
> >    0:	d500409f 	msr	pan, #0x0
> >    4:	1280014a 	mov	w10, #0xfffffff5            	// #-11
> >    8:	f94057eb 	ldr	x11, [sp, #168]
> >    c:	f9800171 	prfm	pstl1strm, [x11]
> > * 10:	885f7d76 	ldxr	w22, [x11] <-- trapping instruction

... so the futex is dereferencing NULL in the LDXR instruction implementing
the atomic_or operation. Normally, that would trigger a translation fault
and the exception fixup handler would cause the function to return -EFAULT.

However, in this case the userspace program has mapped PCI down at 0:

  r0 = openat(0xffffffffffffff9c, &(0x7f0000000300)='./mysys/bus/pci/devices/0000:00:02.0/resource0\x00', 0x2, 0x0)
  mmap(0x0, 0x1012, 0x3, 0x11, r0, 0x0)

and the access from the exclusive instruction generates the external
abort. That's expected, which is why mapping MMIO into userspace is a
bad idea. I suspect you could even make the abort asynchronous if you
wanted to, in which case the kernel couldn't work around it even if it
tried.

Will