CVE-2025-39758

In the Linux kernel, the following vulnerability has been resolved:

RDMA/siw: Fix the sendmsg byte count in siw_tcp_sendpages

Ever since commit c2ff29e99a76 ("siw: Inline do_tcp_sendpages()"), we have been doing this:

static int siw_tcp_sendpages(struct socket *s, struct page *page, int offset, size_t size) [...] / Calculate the number of bytes we need to push, for this page * specifically / size_t bytes = min_t(size_t, PAGE_SIZE - offset, size); / If we can't splice it, then copy it in, as normal / if (!sendpage_ok(page[i])) msg.msg_flags &= ~MSG_SPLICE_PAGES; / Set the bvec pointing to the page, with len $bytes / bvec_set_page(&bvec, page[i], bytes, offset); / Set the iter to $size, aka the size of the whole sendpages (!!!) / iov_iter_bvec(&msg.msg_iter, ITER_SOURCE, &bvec, 1, size); try_page_again: lock_sock(sk); / Sendmsg with $size size (!!!) */ rv = tcp_sendmsg_locked(sk, &msg, size);

This means we've been sending oversized iov_iters and tcp_sendmsg calls for a while. This has a been a benign bug because sendpage_ok() always returned true. With the recent slab allocator changes being slowly introduced into next (that disallow sendpage on large kmalloc allocations), we have recently hit out-of-bounds crashes, due to slight differences in iov_iter behavior between the MSG_SPLICE_PAGES and "regular" copy paths:

(MSG_SPLICE_PAGES) skb_splice_from_iter iov_iter_extract_pages iov_iter_extract_bvec_pages uses i->nr_segs to correctly stop in its tracks before OoB'ing everywhere skb_splice_from_iter gets a "short" read

(!MSG_SPLICE_PAGES) skb_copy_to_page_nocache copy=iov_iter_count [...] copy_from_iter /* this doesn't help */ if (unlikely(iter->count < len)) len = iter->count; iterate_bvec ... and we run off the bvecs

Fix this by properly setting the iov_iter's byte count, plus sending the correct byte count to tcp_sendmsg_locked.

This flaw carries minimal security impact for Red Hat deployments because supported Red Hat Enterprise Linux kernels do not contain the upstream commit that introduced the out-of-bounds handling defect. Furthermore, triggering the condition requires active usage of the Software iWARP (siw) driver, which is neither loaded nor configured by default. In environments where the driver is explicitly loaded, exploitation requires established RDMA network communication and is limited to causing a denial of service through a kernel crash.