From: TAKANO Mitsuhiro <takano32@gmail.com>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: qemu-devel@nongnu.org, Laurent Vivier <laurent@vivier.eu>,
Helge Deller <deller@gmx.de>,
Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Subject: [PATCH v2 1/2] linux-user: validate the fd for a zero-length readv/writev
Date: Sun, 25 Oct 2026 20:51:43 +0000 [thread overview]
Message-ID: <20261025205144.1781959-2-takano32@gmail.com> (raw)
In-Reply-To: <20261025205144.1781959-1-takano32@gmail.com>
lock_iovec() returns NULL with errno left at zero when the vector count
is zero, and the readv/writev family turns that into a successful return
without ever entering the kernel. The kernel checks the file descriptor
before it looks at the vector, so a read from a write-only descriptor
fails with EBADF even when iovcnt is zero, while qemu-user reports
success:
fd = open("/dev/null", O_WRONLY);
readv(fd, NULL, 0); /* kernel: -1 EBADF, qemu-user: 0 */
errno cannot be set in lock_iovec() instead: an empty vector is a
successful no-op on a usable descriptor and only the descriptor decides,
so the syscall has to be issued for the host to answer. Return a shared
empty vector, which is never dereferenced and which unlock_iovec() leaves
alone, so that every caller reaches the host.
This covers readv, writev, preadv, pwritev, preadv2, pwritev2, vmsplice
and recvmsg, which all share lock_iovec(); sendmsg already issued the
syscall for a zero-length vector.
Fixes: f287b2c2d4d2 ("linux-user: Perform more checks on iovec lists")
Signed-off-by: TAKANO Mitsuhiro <takano32@gmail.com>
---
linux-user/syscall.c | 20 +++++++++++++++++---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 0380691a8b..75151c1054 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -3082,6 +3082,13 @@ static void target_to_host_low_high(abi_ulong tlow,
*hhigh = (off >> HOST_LONG_BITS / 2) >> HOST_LONG_BITS / 2;
}
+/*
+ * A zero-length vector is handed to the host so that the syscall is still
+ * issued: the kernel validates the file descriptor before it looks at the
+ * vector. Nothing is ever written to it.
+ */
+static struct iovec empty_iovec;
+
static struct iovec *lock_iovec(int type, abi_ulong target_addr,
abi_ulong count, int copy)
{
@@ -3093,8 +3100,13 @@ static struct iovec *lock_iovec(int type, abi_ulong target_addr,
bool bad_address = false;
if (count == 0) {
- errno = 0;
- return NULL;
+ /*
+ * There is nothing to lock, but returning an error would skip the
+ * syscall: readv(fd, NULL, 0) on a write-only descriptor fails with
+ * EBADF in the kernel, and succeeds when the descriptor is fine, so
+ * only the host syscall can produce the right answer.
+ */
+ return &empty_iovec;
}
if (count > IOV_MAX) {
errno = EINVAL;
@@ -3190,7 +3202,9 @@ static void unlock_iovec(struct iovec *vec, abi_ulong target_addr,
unlock_user(target_vec, target_addr, 0);
}
- g_free(vec);
+ if (vec != &empty_iovec) {
+ g_free(vec);
+ }
}
static inline int target_to_host_sock_type(int *type)
--
2.53.0
next prev parent reply other threads:[~2026-10-25 20:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-25 7:12 [PATCH 1/2] linux-user: validate the fd for a zero-length readv/writev TAKANO Mitsuhiro
2026-10-25 7:12 ` [PATCH 2/2] tests/tcg: check that a zero-length readv/writev validates the fd TAKANO Mitsuhiro
2026-10-25 17:13 ` [PATCH 1/2] linux-user: validate the fd for a zero-length readv/writev Alex Bennée
2026-10-25 20:51 ` [PATCH v2 0/2] " TAKANO Mitsuhiro
2026-10-25 20:51 ` TAKANO Mitsuhiro [this message]
2026-10-25 20:51 ` [PATCH v2 2/2] tests/tcg: check that a zero-length readv/writev validates the fd TAKANO Mitsuhiro
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=20261025205144.1781959-2-takano32@gmail.com \
--to=takano32@gmail.com \
--cc=alex.bennee@linaro.org \
--cc=deller@gmx.de \
--cc=laurent@vivier.eu \
--cc=pierrick.bouvier@oss.qualcomm.com \
--cc=qemu-devel@nongnu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.