[PATCH] net: datagram: fix integer overflow in zerocopy_sg_from_iter

[PATCH] net: datagram: fix integer overflow in zerocopy_sg_from_iter

[Jiangshan Yi]

zerocopy_sg_from_iter() computes the copy length as:

  copy = min_t(int, skb_headlen(skb), iov_iter_count(from));

iov_iter_count() returns size_t.  When it exceeds INT_MAX (e.g. via
io_uring provided buffers), the int cast wraps negative, wins the min()
comparison, and the negative copy propagates into
skb_copy_datagram_from_iter(), which can trigger WARN_ON or corrupt
data.

Use min_t(size_t, ...) so the comparison is done in the correct type.
The result is always <= skb_headlen(skb), which fits in int.

Fixes: 3a654f975bf9 ("new helpers: skb_copy_datagram_from_iter() and zerocopy_sg_from_iter()")
Cc: stable@vger.kernel.org
Signed-off-by: Jiangshan Yi <yijiangshan@kylinos.cn>
---
 net/core/datagram.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/core/datagram.c b/net/core/datagram.c
index c285c6465923..fd8e17d25a3d 100644
--- a/net/core/datagram.c
+++ b/net/core/datagram.c
@@ -783,7 +783,7 @@ EXPORT_SYMBOL(__zerocopy_sg_from_iter);
  */
 int zerocopy_sg_from_iter(struct sk_buff *skb, struct iov_iter *from)
 {
-	int copy = min_t(int, skb_headlen(skb), iov_iter_count(from));
+	int copy = min_t(size_t, skb_headlen(skb), iov_iter_count(from));
 
 	/* copy up to skb headlen */
 	if (skb_copy_datagram_from_iter(skb, 0, from, copy))
-- 
2.25.1

Re: [PATCH] net: datagram: fix integer overflow in zerocopy_sg_from_iter

[Joe Damato]

On Tue, Jul 28, 2026 at 02:42:35PM +0800, Jiangshan Yi wrote:
> zerocopy_sg_from_iter() computes the copy length as:
> 
>   copy = min_t(int, skb_headlen(skb), iov_iter_count(from));
> 
> iov_iter_count() returns size_t.  When it exceeds INT_MAX (e.g. via
> io_uring provided buffers), the int cast wraps negative, wins the min()

idk I looked at the code and it looks to be capped at INT_MAX, so i'm not sure
that the io_uring example could ever happen ?

I think the commit message misstates what is actually possible

> comparison, and the negative copy propagates into
> skb_copy_datagram_from_iter(), which can trigger WARN_ON or corrupt
> data.
> 
> Use min_t(size_t, ...) so the comparison is done in the correct type.
> The result is always <= skb_headlen(skb), which fits in int.
> Fixes: 3a654f975bf9 ("new helpers: skb_copy_datagram_from_iter() and zerocopy_sg_from_iter()")
> Cc: stable@vger.kernel.org
> Signed-off-by: Jiangshan Yi <yijiangshan@kylinos.cn>
> ---
>  net/core/datagram.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/core/datagram.c b/net/core/datagram.c
> index c285c6465923..fd8e17d25a3d 100644
> --- a/net/core/datagram.c
> +++ b/net/core/datagram.c
> @@ -783,7 +783,7 @@ EXPORT_SYMBOL(__zerocopy_sg_from_iter);
>   */
>  int zerocopy_sg_from_iter(struct sk_buff *skb, struct iov_iter *from)
>  {
> -	int copy = min_t(int, skb_headlen(skb), iov_iter_count(from));
> +	int copy = min_t(size_t, skb_headlen(skb), iov_iter_count(from));

I don't get this.

Wouldn't copy need to also be a size_t to be consistent with the general
"idea" of this patch ?

If you leave copy as an int aren't you just shifting the alleged overflow to
the assignment ?

Even if you changed copy to a size_t then.....

>  
>  	/* copy up to skb headlen */
>  	if (skb_copy_datagram_from_iter(skb, 0, from, copy))

this would still be a problem because len here is an int ?

I feel like if you really wanna fix this you would have to use min3 or
something instead of min_t ?

But, I'd probably just leave it and not propose a patch to change this at all.

Re: Re: [PATCH] net: datagram: fix integer overflow in zerocopy_sg_from_iter

[Jiangshan Yi]

Hi Joe,

Thanks for the review, you're right on all points.

I verified that import_ubuf(), __import_iovec(), and import_single_range()
all cap at MAX_RW_COUNT (INT_MAX & PAGE_MASK), which is below INT_MAX.
Both callers of zerocopy_sg_from_iter() (tun.c and tap.c) require
msg_control to be non-NULL for zerocopy, which means the socket sendmsg
path -- always through import_iovec. So the count is always capped, and
my "io_uring provided buffers" claim in the commit message was wrong.

You're also right about the type inconsistency -- leaving copy as int
defeats the purpose, and skb_copy_datagram_from_iter()'s int len remains
a problem regardless.

I did look into io_import_fixed(), the only iov_iter init path without a
MAX_RW_COUNT cap (used by WRITE_FIXED, SEND_ZC with FIXED_BUF, and
URING_CMD). It can produce count > INT_MAX. But this is by design --
BVEC iterators reference pre-registered pinned pages for zero-copy, so
the cap for copy_from_user limits doesn't apply. I traced the consumer
paths (generic_perform_write, tcp_sendmsg, udp_sendmsg, TUN/TAP, block
layer, etc.) and they all handle large counts safely via their own size
limits or chunked processing.

I'll withdraw this patch. Thanks for pushing me to actually understand
the code rather than surface-level pattern matching.

Best,
Jiangshan