CVE-2025-39758
- Source
- https://nvd.nist.gov/vuln/detail/CVE-2025-39758
- Import Source
- https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2025-39758.json
- JSON Data
- https://api.osv.dev/v1/vulns/CVE-2025-39758
- Downstream
- Related
- Published
- 2025-09-11T16:52:27Z
- Modified
- 2025-10-22T16:34:19.584305Z
- Summary
- RDMA/siw: Fix the sendmsg byte count in siw_tcp_sendpages
- Details
-
In the Linux kernel, the following vulnerability has been resolved:
RDMA/siw: Fix the sendmsg byte count in siwtcpsendpages
Ever since commit c2ff29e99a76 ("siw: Inline dotcpsendpages()"), we have been doing this:
static int siwtcpsendpages(struct socket s, struct page *page, int offset, sizet size) [...] /* Calculate the number of bytes we need to push, for this page * specifically */ sizet bytes = mint(sizet, PAGESIZE - offset, size); /* If we can't splice it, then copy it in, as normal */ if (!sendpageok(page[i])) msg.msgflags &= ~MSGSPLICEPAGES; /* Set the bvec pointing to the page, with len $bytes */ bvecsetpage(&bvec, page[i], bytes, offset); /* Set the iter to $size, aka the size of the whole sendpages (!!!) */ ioviterbvec(&msg.msgiter, ITERSOURCE, &bvec, 1, size); trypageagain: locksock(sk); /* Sendmsg with $size size (!!!) */ rv = tcpsendmsglocked(sk, &msg, size);
This means we've been sending oversized ioviters and tcpsendmsg calls for a while. This has a been a benign bug because sendpageok() 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 ioviter behavior between the MSGSPLICEPAGES and "regular" copy paths:
(MSGSPLICEPAGES) skbsplicefromiter ioviterextractpages ioviterextractbvecpages uses i->nrsegs to correctly stop in its tracks before OoB'ing everywhere skbsplicefromiter gets a "short" read
(!MSGSPLICEPAGES) skbcopytopagenocache copy=iovitercount [...] copyfromiter /* 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 ioviter's byte count, plus sending the correct byte count to tcpsendmsg_locked.
- References
-
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- https://git.kernel.org/stable/c/42ebc16d9d2563f1a1ce0f05b643ee68d54fabf8
- https://git.kernel.org/stable/c/5661fdd218c2799001b88c17acd19f4395e4488e
- https://git.kernel.org/stable/c/673cf582fd788af12cdacfb62a6a593083542481
- https://git.kernel.org/stable/c/c18646248fed07683d4cee8a8af933fc4fe83c0d
- https://git.kernel.org/stable/c/edf82bc8150570167a33a7d54627d66614cbf841
Affected packages
Git / git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Affected ranges
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introducedc2ff29e99a764769eb2ce3a1a5585013633ee9a6Fixed5661fdd218c2799001b88c17acd19f4395e4488e
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introducedc2ff29e99a764769eb2ce3a1a5585013633ee9a6Fixed673cf582fd788af12cdacfb62a6a593083542481
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introducedc2ff29e99a764769eb2ce3a1a5585013633ee9a6Fixed42ebc16d9d2563f1a1ce0f05b643ee68d54fabf8
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introducedc2ff29e99a764769eb2ce3a1a5585013633ee9a6Fixededf82bc8150570167a33a7d54627d66614cbf841
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introducedc2ff29e99a764769eb2ce3a1a5585013633ee9a6Fixedc18646248fed07683d4cee8a8af933fc4fe83c0d