linux-stable.git/io_uring, branch linux-6.17.y

io_uring: use WRITE_ONCE for user shared memory

2025-12-18T12:59:35+00:00

[ Upstream commit 93e197e524b14d185d011813b72773a1a49d932d ]

IORING_SETUP_NO_MMAP rings remain user accessible even before the ctx
setup is finalised, so use WRITE_ONCE consistently when initialising
rings.

Fixes: 03d89a2de25bb ("io_uring: support for user allocated memory for rings/sqes")
Signed-off-by: Pavel Begunkov 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin

io_uring/net: ensure vectored buffer node import is tied to notification

2025-12-06T21:27:37+00:00

commit f6041803a831266a2a5a5b5af66f7de0845bcbf3 upstream.

When support for vectored registered buffers was added, the import
itself is using 'req' rather than the notification io_kiocb, sr->notif.
For non-vectored imports, sr->notif is correctly used. This is important
as the lifetime of the two may be different. Use the correct io_kiocb
for the vectored buffer import.

Cc: stable@vger.kernel.org
Fixes: 23371eac7d9a ("io_uring/net: implement vectored reg bufs for zctx")
Reported-by: Google Big Sleep 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

io_uring/cmd_net: fix wrong argument types for skb_queue_splice()

2025-12-01T10:45:39+00:00

commit 46447367a52965e9d35f112f5b26fc8ff8ec443d upstream.

If timestamp retriving needs to be retried and the local list of
SKB's already has entries, then it's spliced back into the socket
queue. However, the arguments for the splice helper are transposed,
causing exactly the wrong direction of splicing into the on-stack
list. Fix that up.

Cc: stable@vger.kernel.org
Reported-by: Google Big Sleep 
Fixes: 9e4ed359b8ef ("io_uring/netcmd: add tx timestamping cmd support")
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

io_uring/rw: ensure allocated iovec gets cleared for early failure

2025-11-24T09:37:46+00:00

commit d3c9c213c0b86ac5dd8fe2c53c24db20f1f510bc upstream.

A previous commit reused the recyling infrastructure for early cleanup,
but this is not enough for the case where our internal caches have
overflowed. If this happens, then the allocated iovec can get leaked if
the request is also aborted early.

Reinstate the previous forced free of the iovec for that situation.

Cc: stable@vger.kernel.org
Reported-by: syzbot+3c93637d7648c24e1fd0@syzkaller.appspotmail.com
Tested-by: syzbot+3c93637d7648c24e1fd0@syzkaller.appspotmail.com
Fixes: 9ac273ae3dc2 ("io_uring/rw: use io_rw_recycle() from cleanup path")
Link: https://lore.kernel.org/io-uring/69122a59.a70a0220.22f260.00fd.GAE@google.com/
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

io_uring/rsrc: don't use blk_rq_nr_phys_segments() as number of bvecs

2025-11-24T09:37:33+00:00

[ Upstream commit 2d0e88f3fd1dcb37072d499c36162baf5b009d41 ]

io_buffer_register_bvec() currently uses blk_rq_nr_phys_segments() as
the number of bvecs in the request. However, bvecs may be split into
multiple segments depending on the queue limits. Thus, the number of
segments may overestimate the number of bvecs. For ublk devices, the
only current users of io_buffer_register_bvec(), virt_boundary_mask,
seg_boundary_mask, max_segments, and max_segment_size can all be set
arbitrarily by the ublk server process.
Set imu->nr_bvecs based on the number of bvecs the rq_for_each_bvec()
loop actually yields. However, continue using blk_rq_nr_phys_segments()
as an upper bound on the number of bvecs when allocating imu to avoid
needing to iterate the bvecs a second time.

Link: https://lore.kernel.org/io-uring/20251111191530.1268875-1-csander@purestorage.com/
Signed-off-by: Caleb Sander Mateos 
Fixes: 27cb27b6d5ea ("io_uring: add support for kernel registered bvecs")
Reviewed-by: Ming Lei 
Reviewed-by: Chaitanya Kulkarni 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin

io_uring: fix unexpected placement on same size resizing

2025-11-24T09:37:26+00:00

[ Upstream commit 437c23357d897f5b5b7d297c477da44b56654d46 ]

There might be many reasons why a user is resizing a ring, e.g. moving
to huge pages or for some memory compaction using IORING_SETUP_NO_MMAP.
Don't bypass resizing, the user will definitely be surprised seeing 0
while the rings weren't actually moved to a new place.

Signed-off-by: Pavel Begunkov 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin

io_uring: fix regbuf vector size truncation

2025-11-13T20:37:46+00:00

commit 146eb58629f45f8297e83d69e64d4eea4b28d972 upstream.

There is a report of io_estimate_bvec_size() truncating the calculated
number of segments that leads to corruption issues. Check it doesn't
overflow "int"s used later. Rough but simple, can be improved on top.

Cc: stable@vger.kernel.org
Fixes: 9ef4cbbcb4ac3 ("io_uring: add infra for importing vectored reg buffers")
Reported-by: Google Big Sleep 
Signed-off-by: Pavel Begunkov 
Reviewed-by: Günther Noack 
Tested-by: Günther Noack 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

io_uring: fix types for region size calulation

2025-11-13T20:37:44+00:00

[ Upstream commit 1fd5367391bf0eeb09e624c4ab45121b54eaab96 ]

->nr_pages is int, it needs type extension before calculating the region
size.

Fixes: a90558b36ccee ("io_uring/memmap: helper for pinning region pages")
Signed-off-by: Pavel Begunkov 
[axboe: style fixup]
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin

io_uring/zcrx: account niov arrays to cgroup

2025-11-13T20:36:51+00:00

[ Upstream commit 31bf77dcc3810e08bcc7d15470e92cdfffb7f7f1 ]

net_iov / freelist / etc. arrays can be quite long, make sure they're
accounted.

Signed-off-by: Pavel Begunkov 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin

io_uring/zcrx: check all niovs filled with dma addresses

2025-11-13T20:36:51+00:00

[ Upstream commit d7ae46b454eb05e3df0d46c2ac9c61416a4d9057 ]

Add a warning if io_populate_area_dma() can't fill in all net_iovs, it
should never happen.

Signed-off-by: Pavel Begunkov 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin