Answer in brief
CVE-2025-39758 records a Critical severity (CVSS 9.8) vulnerability in RDMA/siw: Fix the sendmsg byte count in siw_tcp_sendpages. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 9.8. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Product | Affected versions | Fixed versions |
|---|---|---|
| cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | Not reported | Not reported |
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=c2ff29e99a764769eb2ce3a1a5585013633ee9a6 <5661fdd218c2799001b88c17acd19f4395e4488e || >=c2ff29e99a764769eb2ce3a1a5585013633ee9a6 <673cf582fd788af12cdacfb62a6a593083542481 || >=c2ff29e99a764769eb2ce3a1a5585013633ee9a6 <42ebc16d9d2563f1a1ce0f05b643ee68d54fabf8 || >=c2ff29e99a764769eb2ce3a1a5585013633ee9a6 <edf82bc8150570167a33a7d54627d66614cbf841 || >=c2ff29e99a764769eb2ce3a1a5585013633ee9a6 <c18646248fed07683d4cee8a8af933fc4fe83c0d | 5661fdd218c2799001b88c17acd19f4395e4488e, 673cf582fd788af12cdacfb62a6a593083542481, 42ebc16d9d2563f1a1ce0f05b643ee68d54fabf8, edf82bc8150570167a33a7d54627d66614cbf841, c18646248fed07683d4cee8a8af933fc4fe83c0d |
| Linux/Linuxgeneric | 6.5 | Not reported |
| Linux/Linuxgeneric | >=a19a58ab12695abb91a4e8ecf62cc0bc5badefbe <b47c4b7cb78b6382c6d1af0bfc0d8218e4f445cc || >=c2ff29e99a764769eb2ce3a1a5585013633ee9a6 <5661fdd218c2799001b88c17acd19f4395e4488e || >=c2ff29e99a764769eb2ce3a1a5585013633ee9a6 <673cf582fd788af12cdacfb62a6a593083542481 || >=c2ff29e99a764769eb2ce3a1a5585013633ee9a6 <42ebc16d9d2563f1a1ce0f05b643ee68d54fabf8 || >=c2ff29e99a764769eb2ce3a1a5585013633ee9a6 <edf82bc8150570167a33a7d54627d66614cbf841 || >=c2ff29e99a764769eb2ce3a1a5585013633ee9a6 <c18646248fed07683d4cee8a8af933fc4fe83c0d | b47c4b7cb78b6382c6d1af0bfc0d8218e4f445cc, 5661fdd218c2799001b88c17acd19f4395e4488e, 673cf582fd788af12cdacfb62a6a593083542481, 42ebc16d9d2563f1a1ce0f05b643ee68d54fabf8, edf82bc8150570167a33a7d54627d66614cbf841, c18646248fed07683d4cee8a8af933fc4fe83c0d |
Published upstream
Sep 11, 2025
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 23, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
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.
Quoted source text, attributed separately from HOL analysis.