From: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
To: Qingyue Zhang <chunzhennn@qq.com>, axboe@kernel.dk
Cc: io-uring@vger.kernel.org, linux-kernel@vger.kernel.org,
Suoxing Zhang <aftern00n@qq.com>,
cve@kernel.org, Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH 1/2] io_uring/kbuf: fix signedness in this_len calculation
Date: Tue, 20 Jan 2026 23:03:15 +0530 [thread overview]
Message-ID: <b53d5207-0dbc-4e1e-93e7-e51cb6c85383@oracle.com> (raw)
In-Reply-To: <tencent_4DBB3674C0419BEC2C0C525949DA410CA307@qq.com>
Hi,
I have a question regarding the Fixes tag for this.
On 27/08/25 17:13, Qingyue Zhang wrote:
> When importing and using buffers, buf->len is considered unsigned.
> However, buf->len is converted to signed int when committing. This
> can lead to unexpected behavior if buffer is large enough to be
> interpreted as a negative value. Make min_t calculation unsigned.
>
> Co-developed-by: Suoxing Zhang <aftern00n@qq.com>
> Signed-off-by: Suoxing Zhang <aftern00n@qq.com>
> Signed-off-by: Qingyue Zhang <chunzhennn@qq.com>
In the upstream merged commit:
commit c64eff368ac676e8540344d27a3de47e0ad90d21
Author: Qingyue Zhang <chunzhennn@qq.com>
Date: Wed Aug 27 19:43:39 2025 +0800
io_uring/kbuf: fix signedness in this_len calculation
When importing and using buffers, buf->len is considered unsigned.
However, buf->len is converted to signed int when committing. This can
lead to unexpected behavior if the buffer is large enough to be
interpreted as a negative value. Make min_t calculation unsigned.
Fixes: ae98dbf43d75 ("io_uring/kbuf: add support for incremental
buffer consumption")
Co-developed-by: Suoxing Zhang <aftern00n@qq.com>
Signed-off-by: Suoxing Zhang <aftern00n@qq.com>
Signed-off-by: Qingyue Zhang <chunzhennn@qq.com>
Link:
https://lore.kernel.org/r/tencent_4DBB3674C0419BEC2C0C525949DA410CA307@qq.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
diff --git a/io_uring/kbuf.c b/io_uring/kbuf.c
index f2d2cc319faa..81a13338dfab 100644
--- a/io_uring/kbuf.c
+++ b/io_uring/kbuf.c
@@ -39,7 +39,7 @@ static bool io_kbuf_inc_commit(struct io_buffer_list
*bl, int len)
u32 this_len;
buf = io_ring_head_to_buf(bl->buf_ring, bl->head,
bl->mask);
- this_len = min_t(int, len, buf->len);
+ this_len = min_t(u32, len, buf->len);
buf->len -= this_len;
if (buf->len) {
buf->addr += this_len;
I see the Fixes tag documented is "Fixes: ae98dbf43d75 ("io_uring/kbuf:
add support for incremental buffer consumption")"
I think a more accurate Fixes tag is "Fixes: cf9536e550dd
("io_uring/kbuf: enable bundles for incrementally consumed buffers")" ,
Reason: Commit cf9536e550dd243a1681fdbf804221527da20a80 is the first to
move incremental-buffer accounting into the new helper
io_kbuf_inc_commit(), introducing this_len = min_t(int, len, buf->len);.
The signed int here is exactly what
c64eff368ac676e8540344d27a3de47e0ad90d21 corrects.
I am asking this so we can correct the vulnerable commit for
CVE-2025-39822. Currently due to a different broken commit 6.12.y is
marked as vulnerable [1]. If the above new Fixes tag is correct only
kernels newer than 6.15 are affected.
[1] https://lore.kernel.org/all/2025091616-CVE-2025-39822-454e@gregkh/
Thanks,
Harshit
> ---
> io_uring/kbuf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/io_uring/kbuf.c b/io_uring/kbuf.c
> index f2d2cc319faa..81a13338dfab 100644
> --- a/io_uring/kbuf.c
> +++ b/io_uring/kbuf.c
> @@ -39,7 +39,7 @@ static bool io_kbuf_inc_commit(struct io_buffer_list *bl, int len)
> u32 this_len;
>
> buf = io_ring_head_to_buf(bl->buf_ring, bl->head, bl->mask);
> - this_len = min_t(int, len, buf->len);
> + this_len = min_t(u32, len, buf->len);
> buf->len -= this_len;
> if (buf->len) {
> buf->addr += this_len;
next prev parent reply other threads:[~2026-01-20 17:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-27 11:43 [PATCH 1/2] io_uring/kbuf: fix signedness in this_len calculation Qingyue Zhang
2025-08-27 14:40 ` Jens Axboe
2026-01-20 17:33 ` Harshit Mogalapalli [this message]
2026-01-20 17:38 ` Jens Axboe
2026-01-20 17:41 ` Harshit Mogalapalli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b53d5207-0dbc-4e1e-93e7-e51cb6c85383@oracle.com \
--to=harshit.m.mogalapalli@oracle.com \
--cc=aftern00n@qq.com \
--cc=axboe@kernel.dk \
--cc=chunzhennn@qq.com \
--cc=cve@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=io-uring@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox