Re: [RFC PATCH] io_uring/cmd: don't skip completion for a non-armed multishot uring_cmd

> Hi everyone,
>
> Just a gentle ping on this patch.
>
> The issue is syzbot-reproduced and the proposed fix has been run with 
> #syz test.

unknown command "test."

> The patch addresses the leak in the core |io_uring_cmd()|path rather than
> relying on individual providers to handle |IORING_URING_CMD_MULTISHOT|.
>
> Could someone take a look when you get a chance?
>
> Thanks,
> Vasileios
>
>
> On 8/11/26 10:42 PM, Vasileios Almpanis wrote:
>> io_uring_cmd() treats any uring_cmd carrying IORING_URING_CMD_MULTISHOT
>> that returns >= 0 as "multishot armed, completion deferred" and returns
>> IOU_ISSUE_SKIP_COMPLETE, expecting the provider to complete the request
>> later. But the flag is user-controlled and validated only against buffer
>> select, not against provider capability. A ->uring_cmd() handler that
>> does not implement multishot and returns a normal >= 0 result then has
>> its request skipped and never completed, leaking the io_kiocb and its
>> io_async_cmd:
>>
>>    BUG: memory leak
>>    unreferenced object (size 248):
>>      kmem_cache_alloc_bulk_noprof+0x272/0x3f0
>>      __io_alloc_req_refill+0x4a/0x150
>>      io_submit_sqes.cold+0x16e/0x20b
>>      __do_sys_io_uring_enter+0x56d/0xd60
>>
>> syzbot hit this via ublk UBLK_U_CMD_ADD_DEV, but it is kernel-wide: the
>> same leak reproduces with SOCKET_URING_OP_SIOCINQ on any socket fd, which
>> returns the queued byte count and never inspects cmd->flags. No in-tree
>> provider of multishot actually returns >= 0. Both io_cmd_poll_multishot()
>> and ublk_handle_batch_fetch_cmd return -EIOCBQUEUED,
>>
>> Only skip completion when the command is really multishot, i.e.
>> REQ_F_APOLL_MULTISHOT is set. Otherwise fall through and complete the
>> request normally with its result.
>>
>> Fixes: 620a50c92700 ("io_uring: uring_cmd: add multishot support")
>> Reported-by: [email protected]
>> Closes: https://syzkaller.appspot.com/bug?extid=a4ccdd7ebf452e4d4701
>> Tested-by: [email protected]
>> Signed-off-by: Vasileios Almpanis <[email protected]>
>> ---
>> Questions / Notes:
>> - I put this in the core io_uring_cmd() rather than in provider specific
>>    code because the leak is independent of the provider. From my research
>>    so far no ->uring_cmd() rejects IORING_URING_CMD_MULTISHOT, they just
>>    ignore it. The flag is only validated against buffer-select in
>>    io_uring_cmd_prep(). So any handler that returns a plain >= 0 result
>>    with the user-set flag leaks.
>> - Instead of checking if it has been really armed should we just drop
>>    the >= 0 check? The in-tree code that supports multishot returns
>>    -EIOCBQUEUED from what I have seen so far.
>> ---
>>   io_uring/uring_cmd.c | 3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/io_uring/uring_cmd.c b/io_uring/uring_cmd.c
>> index c14c22cff49e..a2899a852879 100644
>> --- a/io_uring/uring_cmd.c
>> +++ b/io_uring/uring_cmd.c
>> @@ -269,7 +269,8 @@ int io_uring_cmd(struct io_kiocb *req, unsigned int issue_flags)
>>   	}
>>   
>>   	ret = file->f_op->uring_cmd(ioucmd, issue_flags);
>> -	if (ioucmd->flags & IORING_URING_CMD_MULTISHOT) {
>> +	if ((ioucmd->flags & IORING_URING_CMD_MULTISHOT) &&
>> +	    (req->flags & REQ_F_APOLL_MULTISHOT)) {
>>   		if (ret >= 0)
>>   			return IOU_ISSUE_SKIP_COMPLETE;
>>   	}
>>
>> ---
>> base-commit: d58772d8520c7ef247c4b95c9bd76d3a25da9ff5
>> change-id: 20260811-io_uring-169337c74617
>>
>> Best regards,
>> --
>> Vasileios Almpanis <[email protected]>
>>