Re: [syzbot] [kernel?] general protection fault in try_to_wake_up (3)

[Jens Axboe <axboe@kernel.dk>]

On 9/4/25 10:28 AM, Sebastian Andrzej Siewior wrote:
> On 2025-09-03 12:51:09 [-0600], Jens Axboe wrote:
>>> The syz-reproducer lists only:
>>> | timer_create(0x0, &(0x7f0000000080)={0x0, 0x11, 0x0, @thr={0x0, 0x0}}, &(0x7f0000000000))
>>> | timer_settime(0x0, 0x0, &(0x7f0000000240)={{0x0, 0x8}, {0x0, 0x9}}, 0x0)
>>> | futex(&(0x7f000000cffc), 0x80000000000b, 0x0, 0x0, &(0x7f0000048000), 0x0)
>>> | futex(&(0x7f000000cffc), 0xc, 0x1, 0x0, &(0x7f0000048000), 0x0)
>>>
>>> and that is probably why it can't come up with C-reproducer.
>>> The whole log has (filtered) the following lines:
>>>
>>> | io_uring_setup(0x85a, &(0x7f0000000180)={0x0, 0x58b9, 0x1, 0x2, 0x383})
>>> | syz_io_uring_setup(0x88f, &(0x7f0000000300)={0x0, 0xaedf, 0x0, 0x0, 0x25d}, &(0x7f0000000140)=<r0=>0x0, &(0x7f0000000280)=<r1=>0x0)
>>> | syz_memcpy_off$IO_URING_METADATA_GENERIC(r0, 0x4, &(0x7f0000000080)=0xfffffffc, 0x0, 0x4)
>>> | syz_io_uring_submit(r0, r1, &(0x7f00000001c0)=@IORING_OP_RECVMSG={0xa, 0x8, 0x1, r2, 0x0, &(0x7f0000000440)={0x0, 0x0, 0x0}, 0x0, 0x40000020, 0x1, {0x2}})
>>>
>>> This should explain the how the waiter got NULL. There is no private
>>> flag so that is how they interact with each other.
>>> Do we want this:
>>>
>>> diff --git a/kernel/futex/requeue.c b/kernel/futex/requeue.c
>>> index c716a66f86929..0c98256ebdcb7 100644
>>> --- a/kernel/futex/requeue.c
>>> +++ b/kernel/futex/requeue.c
>>> @@ -312,6 +312,8 @@ futex_proxy_trylock_atomic(u32 __user *pifutex, struct futex_hash_bucket *hb1,
>>>  	if (!top_waiter->rt_waiter || top_waiter->pi_state)
>>>  		return -EINVAL;
> 
> I've been poking at this today and I have one problem with my
> explanation:
> The io_uring code initializes its futex_q with futex_q_init. At this
> point futex_q::rt_waiter is set to NULL and never set to something else.
> We should bail out here instead of going further.
> Only the PI bits set rt_waiter. Only io_uring sets task to NULL.
> I'm hopeless, this makes no sense.

Was on the road, and now back at least for a day or two... So I took a
gander at this one too. One thing that puzzles me is the io_uring traces
in that syzbot log - if they are to be trusted, it only ever submits an
io_uring RECVMSG request? IOW, no futex usage on the io_uring side at
all?

Going to try and download the disk image and kernel and see if I can
actually run this locally.

-- 
Jens Axboe