[PATCH] io_uring/net: fix netmsg_cache iovec leak on BIND and CONNECT

[PATCH] io_uring/net: fix netmsg_cache iovec leak on BIND and CONNECT

[Yang Xiuwei]

BIND and CONNECT allocate struct io_async_msghdr from netmsg_cache via
io_msg_alloc_async(). When a prior SENDMSG left a heap-allocated iovec[]
in the cached header, REQ_F_NEED_CLEANUP is set. Neither opcode had a
cleanup handler, so io_clean_op() would kfree(async_data) without
freeing the iovec on prep failure or cancellation. io_bind() also
omitted io_req_msg_cleanup() on the issue success path,
unlike io_connect().

Add io_sendmsg_recvmsg_cleanup for both opcodes and recycle the async
header from io_bind() after issue, matching CONNECT.

Fixes: 7481fd93fa0a ("io_uring: Introduce IORING_OP_BIND")
Signed-off-by: Yang Xiuwei <yangxiuwei@kylinos.cn>
---
 io_uring/net.c   | 3 ++-
 io_uring/opdef.c | 6 ++++++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/io_uring/net.c b/io_uring/net.c
index 8df15b639358..0382be472712 100644
--- a/io_uring/net.c
+++ b/io_uring/net.c
@@ -1855,8 +1855,9 @@ int io_bind(struct io_kiocb *req, unsigned int issue_flags)
 	ret = __sys_bind_socket(sock, &io->addr, bind->addr_len);
 	if (ret < 0)
 		req_set_fail(req);
+	io_req_msg_cleanup(req, issue_flags);
 	io_req_set_res(req, ret, 0);
-	return 0;
+	return IOU_COMPLETE;
 }
 
 int io_listen_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
diff --git a/io_uring/opdef.c b/io_uring/opdef.c
index c3ef52b70811..3ee020701fc1 100644
--- a/io_uring/opdef.c
+++ b/io_uring/opdef.c
@@ -658,6 +658,9 @@ const struct io_cold_def io_cold_defs[] = {
 	},
 	[IORING_OP_CONNECT] = {
 		.name			= "CONNECT",
+#if defined(CONFIG_NET)
+		.cleanup		= io_sendmsg_recvmsg_cleanup,
+#endif
 	},
 	[IORING_OP_FALLOCATE] = {
 		.name			= "FALLOCATE",
@@ -816,6 +819,9 @@ const struct io_cold_def io_cold_defs[] = {
 	},
 	[IORING_OP_BIND] = {
 		.name			= "BIND",
+#if defined(CONFIG_NET)
+		.cleanup		= io_sendmsg_recvmsg_cleanup,
+#endif
 	},
 	[IORING_OP_LISTEN] = {
 		.name			= "LISTEN",
-- 
2.25.1

Re: [PATCH] io_uring/net: fix netmsg_cache iovec leak on BIND and CONNECT

[Yang Xiuwei]

Hi Jens,

Please drop this patch.

After rebasing on the latest io_uring tree, I noticed that this issue
has already been fixed upstream by:

  3979840cd858 ("io_uring/net: Avoid msghdr on op_connect/op_bind async data")

BIND and CONNECT no longer allocate async data from netmsg_cache via
io_msg_alloc_async(). They now use struct sockaddr_storage directly, so
the iovec leak path described in my patch no longer exists. My fix is
also incorrect on the current code base.

Sorry for the noise.

Thanks,
Yang Xiuwei

Re: [PATCH] io_uring/net: fix netmsg_cache iovec leak on BIND and CONNECT

[Jens Axboe]

On 6/16/26 9:30 PM, Yang Xiuwei wrote:
> Hi Jens,
> 
> Please drop this patch.

Haven't picked it up, nothing to drop.

> After rebasing on the latest io_uring tree, I noticed that this issue
> has already been fixed upstream by:
> 
>   3979840cd858 ("io_uring/net: Avoid msghdr on op_connect/op_bind async data")
> 
> BIND and CONNECT no longer allocate async data from netmsg_cache via
> io_msg_alloc_async(). They now use struct sockaddr_storage directly, so
> the iovec leak path described in my patch no longer exists. My fix is
> also incorrect on the current code base.

But then we should probably mark 3979840cd858 for stable, then? Gabriel,
can you take a look? Currently traveling...

-- 
Jens Axboe

Re: [PATCH] io_uring/net: fix netmsg_cache iovec leak on BIND and CONNECT

[Gabriel Krisman Bertazi]

Jens Axboe <axboe@kernel.dk> writes:

> On 6/16/26 9:30 PM, Yang Xiuwei wrote:
>> Hi Jens,
>> 
>> Please drop this patch.
>
> Haven't picked it up, nothing to drop.
>
>> After rebasing on the latest io_uring tree, I noticed that this issue
>> has already been fixed upstream by:
>> 
>>   3979840cd858 ("io_uring/net: Avoid msghdr on op_connect/op_bind async data")
>> 
>> BIND and CONNECT no longer allocate async data from netmsg_cache via
>> io_msg_alloc_async(). They now use struct sockaddr_storage directly, so
>> the iovec leak path described in my patch no longer exists. My fix is
>> also incorrect on the current code base.
>
> But then we should probably mark 3979840cd858 for stable, then? Gabriel,
> can you take a look? Currently traveling...

ack. will do.

-- 
Gabriel Krisman Bertazi