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

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