ghsa-59wj-ff55-qrvj
Vulnerability from github
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.
{
"affected": [],
"aliases": [
"CVE-2025-39758"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-11T17:15:39Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/siw: Fix the sendmsg byte count in siw_tcp_sendpages\n\nEver since commit c2ff29e99a76 (\"siw: Inline do_tcp_sendpages()\"),\nwe have been doing this:\n\nstatic int siw_tcp_sendpages(struct socket *s, struct page **page, int offset,\n size_t size)\n[...]\n /* Calculate the number of bytes we need to push, for this page\n * specifically */\n size_t bytes = min_t(size_t, PAGE_SIZE - offset, size);\n /* If we can\u0027t splice it, then copy it in, as normal */\n if (!sendpage_ok(page[i]))\n msg.msg_flags \u0026= ~MSG_SPLICE_PAGES;\n /* Set the bvec pointing to the page, with len $bytes */\n bvec_set_page(\u0026bvec, page[i], bytes, offset);\n /* Set the iter to $size, aka the size of the whole sendpages (!!!) */\n iov_iter_bvec(\u0026msg.msg_iter, ITER_SOURCE, \u0026bvec, 1, size);\ntry_page_again:\n lock_sock(sk);\n /* Sendmsg with $size size (!!!) */\n rv = tcp_sendmsg_locked(sk, \u0026msg, size);\n\nThis means we\u0027ve been sending oversized iov_iters and tcp_sendmsg calls\nfor a while. This has a been a benign bug because sendpage_ok() always\nreturned true. With the recent slab allocator changes being slowly\nintroduced into next (that disallow sendpage on large kmalloc\nallocations), we have recently hit out-of-bounds crashes, due to slight\ndifferences in iov_iter behavior between the MSG_SPLICE_PAGES and\n\"regular\" copy paths:\n\n(MSG_SPLICE_PAGES)\nskb_splice_from_iter\n iov_iter_extract_pages\n iov_iter_extract_bvec_pages\n uses i-\u003enr_segs to correctly stop in its tracks before OoB\u0027ing everywhere\n skb_splice_from_iter gets a \"short\" read\n\n(!MSG_SPLICE_PAGES)\nskb_copy_to_page_nocache copy=iov_iter_count\n [...]\n copy_from_iter\n /* this doesn\u0027t help */\n if (unlikely(iter-\u003ecount \u003c len))\n len = iter-\u003ecount;\n iterate_bvec\n ... and we run off the bvecs\n\nFix this by properly setting the iov_iter\u0027s byte count, plus sending the\ncorrect byte count to tcp_sendmsg_locked.",
"id": "GHSA-59wj-ff55-qrvj",
"modified": "2025-09-11T18:35:52Z",
"published": "2025-09-11T18:35:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39758"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/42ebc16d9d2563f1a1ce0f05b643ee68d54fabf8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5661fdd218c2799001b88c17acd19f4395e4488e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/673cf582fd788af12cdacfb62a6a593083542481"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c18646248fed07683d4cee8a8af933fc4fe83c0d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/edf82bc8150570167a33a7d54627d66614cbf841"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.