ghsa-6r55-jr8w-3x3r
Vulnerability from github
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix unbuffered write error handling
If all the subrequests in an unbuffered write stream fail, the subrequest collector doesn't update the stream->transferred value and it retains its initial LONG_MAX value. Unfortunately, if all active streams fail, then we take the smallest value of { LONG_MAX, LONG_MAX, ... } as the value to set in wreq->transferred - which is then returned from ->write_iter().
LONG_MAX was chosen as the initial value so that all the streams can be quickly assessed by taking the smallest value of all stream->transferred - but this only works if we've set any of them.
Fix this by adding a flag to indicate whether the value in stream->transferred is valid and checking that when we integrate the values. stream->transferred can then be initialised to zero.
This was found by running the generic/750 xfstest against cifs with cache=none. It splices data to the target file. Once (if) it has used up all the available scratch space, the writes start failing with ENOSPC. This causes ->write_iter() to fail. However, it was returning wreq->transferred, i.e. LONG_MAX, rather than an error (because it thought the amount transferred was non-zero) and iter_file_splice_write() would then try to clean up that amount of pipe bufferage - leading to an oops when it overran. The kernel log showed:
CIFS: VFS: Send error in write = -28
followed by:
BUG: kernel NULL pointer dereference, address: 0000000000000008
with:
RIP: 0010:iter_file_splice_write+0x3a4/0x520
do_splice+0x197/0x4e0
or:
RIP: 0010:pipe_buf_release (include/linux/pipe_fs_i.h:282)
iter_file_splice_write (fs/splice.c:755)
Also put a warning check into splice to announce if ->write_iter() returned that it had written more than it was asked to.
{
"affected": [],
"aliases": [
"CVE-2025-39723"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-05T18:15:50Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfs: Fix unbuffered write error handling\n\nIf all the subrequests in an unbuffered write stream fail, the subrequest\ncollector doesn\u0027t update the stream-\u003etransferred value and it retains its\ninitial LONG_MAX value. Unfortunately, if all active streams fail, then we\ntake the smallest value of { LONG_MAX, LONG_MAX, ... } as the value to set\nin wreq-\u003etransferred - which is then returned from -\u003ewrite_iter().\n\nLONG_MAX was chosen as the initial value so that all the streams can be\nquickly assessed by taking the smallest value of all stream-\u003etransferred -\nbut this only works if we\u0027ve set any of them.\n\nFix this by adding a flag to indicate whether the value in\nstream-\u003etransferred is valid and checking that when we integrate the\nvalues. stream-\u003etransferred can then be initialised to zero.\n\nThis was found by running the generic/750 xfstest against cifs with\ncache=none. It splices data to the target file. Once (if) it has used up\nall the available scratch space, the writes start failing with ENOSPC.\nThis causes -\u003ewrite_iter() to fail. However, it was returning\nwreq-\u003etransferred, i.e. LONG_MAX, rather than an error (because it thought\nthe amount transferred was non-zero) and iter_file_splice_write() would\nthen try to clean up that amount of pipe bufferage - leading to an oops\nwhen it overran. The kernel log showed:\n\n CIFS: VFS: Send error in write = -28\n\nfollowed by:\n\n BUG: kernel NULL pointer dereference, address: 0000000000000008\n\nwith:\n\n RIP: 0010:iter_file_splice_write+0x3a4/0x520\n do_splice+0x197/0x4e0\n\nor:\n\n RIP: 0010:pipe_buf_release (include/linux/pipe_fs_i.h:282)\n iter_file_splice_write (fs/splice.c:755)\n\nAlso put a warning check into splice to announce if -\u003ewrite_iter() returned\nthat it had written more than it was asked to.",
"id": "GHSA-6r55-jr8w-3x3r",
"modified": "2025-09-05T18:31:27Z",
"published": "2025-09-05T18:31:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39723"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/387164a2b97e1f5404c6d0049a7409bac7d2bc5b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a3de58b12ce074ec05b8741fa28d62ccb1070468"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f08c80af3c9a9849cd178b4843b7c01d103506a1"
}
],
"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.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- 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.