From: Wang Haoran <haoranwangsec@gmail.com>
To: viro@zeniv.linux.org.uk, akpm@linux-foundation.org
Cc: linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org,
Wang Haoran <haoranwangsec@gmail.com>
Subject: [PATCH] iov_iter: use kmemdup_array for dup_iter to harden against overflow
Date: Mon, 13 Apr 2026 14:06:55 +0800 [thread overview]
Message-ID: <20260413060655.1139141-1-haoranwangsec@gmail.com> (raw)
While auditing the Linux 7.0-rc2 kernel, I identified a potential security
vulnerability in the iov_iter framework's memory allocation logic.
The dup_iter() function, which is exported via EXPORT_SYMBOL, currently
uses kmemdup() with a raw multiplication to allocate the duplicate iovec array:
new->iov = kmemdup(from->iov, nr_segs * sizeof(struct iovec), gfp);
The hazard here is that dup_iter() relies on a primitive multiplication without
any integrated overflow check. Since nr_segs is often derived from user-space
input, this line is vulnerable to integer overflow (on 32-bit systems or
via type narrowing), potentially leading to a small allocation followed by a
large out-of-bounds memory copy. Furthermore, it allows for unbounded memory
allocations, as the function lacks intrinsic knowledge of safe limits.
On the 7.0-rc2 branch, several high-impact callchains still rely on this
exported function:
drivers/usb/gadget/function/f_fs.c:
The ffs_epfile_read_iter() path demonstrates why relying on dup_iter() is
dangerous: it performs allocation based on user input before verifying driver
state. This confirms that dup_iter() must be hardened internally as it cannot
assume pre-validated input.
drivers/usb/gadget/legacy/inode.c:
The ep_read_iter() path illustrates how dup_iter()’s lack of boundary awareness
compounds resource risks. When combined with other allocations, it creates
a multiplier effect for kernel memory pressure.
This patch replaces kmemdup() with kmemdup_array(), which utilizes
check_mul_overflow() to ensure the allocation size is calculated safely,
hardening dup_iter() against malicious or malformed inputs from its callers
Signed-off-by: Wang Haoran <haoranwangsec@gmail.com>
---
lib/iov_iter.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/iov_iter.c b/lib/iov_iter.c
index 0a63c7fba..63aa8b6e3 100644
--- a/lib/iov_iter.c
+++ b/lib/iov_iter.c
@@ -1224,13 +1224,13 @@ const void *dup_iter(struct iov_iter *new, struct iov_iter *old, gfp_t flags)
{
*new = *old;
if (iov_iter_is_bvec(new))
- return new->bvec = kmemdup(new->bvec,
- new->nr_segs * sizeof(struct bio_vec),
+ return new->bvec = kmemdup_array(new->bvec,
+ new->nr_segs, sizeof(struct bio_vec),
flags);
else if (iov_iter_is_kvec(new) || iter_is_iovec(new))
/* iovec and kvec have identical layout */
- return new->__iov = kmemdup(new->__iov,
- new->nr_segs * sizeof(struct iovec),
+ return new->__iov = kmemdup_array(new->__iov,
+ new->nr_segs, sizeof(struct iovec),
flags);
return NULL;
}
--
2.43.0
next reply other threads:[~2026-04-13 6:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-13 6:06 Wang Haoran [this message]
2026-04-14 8:18 ` [PATCH] iov_iter: use kmemdup_array for dup_iter to harden against overflow Christoph Hellwig
2026-04-14 9:46 ` Christian Brauner
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=20260413060655.1139141-1-haoranwangsec@gmail.com \
--to=haoranwangsec@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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