aboutsummaryrefslogtreecommitdiffstats
path: root/io_uring
diff options
context:
space:
mode:
authorJens Axboe <axboe@kernel.dk>2024-02-01 06:42:36 -0700
committerJens Axboe <axboe@kernel.dk>2024-02-01 06:42:36 -0700
commit72bd80252feeb3bef8724230ee15d9f7ab541c6e (patch)
treedabc690cf67a86760697180a038ba4b9e4a4b82b /io_uring
parent76b367a2d83163cf19173d5cb0b562acbabc8eac (diff)
downloadlinux-72bd80252feeb3bef8724230ee15d9f7ab541c6e.tar.gz
io_uring/net: fix sr->len for IORING_OP_RECV with MSG_WAITALL and buffers
If we use IORING_OP_RECV with provided buffers and pass in '0' as the length of the request, the length is retrieved from the selected buffer. If MSG_WAITALL is also set and we get a short receive, then we may hit the retry path which decrements sr->len and increments the buffer for a retry. However, the length is still zero at this point, which means that sr->len now becomes huge and import_ubuf() will cap it to MAX_RW_COUNT and subsequently return -EFAULT for the range as a whole. Fix this by always assigning sr->len once the buffer has been selected. Cc: stable@vger.kernel.org Fixes: 7ba89d2af17a ("io_uring: ensure recv and recvmsg handle MSG_WAITALL correctly") Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'io_uring')
-rw-r--r--io_uring/net.c1
1 files changed, 1 insertions, 0 deletions
diff --git a/io_uring/net.c b/io_uring/net.c
index a12ff69e684348..43bc9a5f96f9d1 100644
--- a/io_uring/net.c
+++ b/io_uring/net.c
@@ -923,6 +923,7 @@ retry_multishot:
if (!buf)
return -ENOBUFS;
sr->buf = buf;
+ sr->len = len;
}
ret = import_ubuf(ITER_DEST, sr->buf, len, &msg.msg_iter);