CVE-2025-39758: RDMA/siw: Fix the sendmsg byte count in siw_tcp_sendpages
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.
Security readout for executives and security teams
Plain-English summary
A Linux software iWARP RDMA networking bug can make the kernel process more data than a page descriptor contains, causing out-of-bounds access and crashes. The supplied assessment rates it critical, but the available evidence does not establish practical compromise or exploitation in the wild.
Executive priority
Treat this as an urgent kernel maintenance issue on systems using RDMA/siw, especially network-facing or high-availability infrastructure. Prioritize accurate exposure validation because the critical CVSS overstates what the supplied technical evidence alone proves. Patch confirmed users promptly and obtain distribution-specific guidance for other Linux systems.
Technical view
The siw_tcp_sendpages function passed the total transfer size to a single-page iterator and tcp_sendmsg_locked instead of that page's byte count. When the non-splice copy path is selected, iteration can run beyond the bvec. Stable fixes use the page-specific count for both operations.
Likely exposure
Exposure is limited to affected Linux kernels where the RDMA/siw software iWARP send path is present and exercised under triggering allocator and page conditions. The bundle lists affected releases from 6.5 through 6.17, with several fixed stable commits, but does not provide complete distribution-package mapping or confirm internet exposure.
Exploitation context
The supplied CVSS is 9.8 and describes network-accessible, unauthenticated impact to confidentiality, integrity, and availability. However, the source narrative documents out-of-bounds crashes, not demonstrated code execution or data disclosure. This CVE is not listed as KEV, and the supplied sources provide no evidence of active exploitation or public weaponization.
Researcher notes
The failure depends on a size mismatch between a one-element bvec and the iterator/send length. MSG_SPLICE_PAGES stops at the segment boundary, while the regular copy path may overrun it. Recent slab allocator behavior makes that path reachable for some allocations. The sources do not establish reliable exploitation beyond crashes or identify a CWE.
Mitigation direction
Update to a vendor kernel containing the applicable stable fix.
Consult the Linux distribution vendor for exact fixed package and backport status.
Prioritize remediation on systems actively using RDMA/siw software iWARP.
Apply normal change controls and reboot into the corrected kernel.
Validation and detection
Inventory running kernel versions and distribution patch levels.
Determine whether RDMA/siw is present and used on each affected host.
Confirm the applicable stable fix is included in the installed kernel source or package advisory.
Review kernel logs and crash records for related out-of-bounds faults.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2025-39758 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
7Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.