[syzbot] [kernel?] Internal error in futex_wake_op

[syzbot]

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+417a6b...@syzkaller.appspotmail.com

futex_wake_op: syz.0.17 tries to shift op by 144; fix this program
Internal error: synchronous external abort: 0000000096000010 [#1] SMP
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
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


---
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 report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

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

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

[Thomas Gleixner]

On Thu, Aug 27 2026 at 11:52, syzbot wrote:

CC+: ARM64 people...

[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+417a6b...@syzkaller.appspotmail.com
> >
> > 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!

X11 is NULL...

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

[Thomas Gleixner]

On Fri, Sep 04 2026 at 19:04, Will Deacon wrote:
> On Fri, Sep 04, 2026 at 07:40:42AM +0200, Thomas Gleixner wrote:
>> On Thu, Aug 27 2026 at 11:52, syzbot wrote:
>> > 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!

which confused me :)

>> > x11: 0000000000000000 x10: 00000000fffffff5 x9 : 0000000000000000
>
> X11 is NULL...
>

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

I assume there is nothing we can do about that. But that mmap() requires
root, so ...