{"cve":"CVE-2025-39723","nvd":{"published":"2025-09-05T18:15:50.043","modified":"2026-10-19T21:10:00.160","status":"Modified","description":"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't update the stream->transferred 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->transferred - which is then returned from ->write_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->transferred -\nbut this only works if we've set any of them.\n\nFix this by adding a flag to indicate whether the value in\nstream->transferred is valid and checking that when we integrate the\nvalues.  stream->transferred 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 ->write_iter() to fail.  However, it was returning\nwreq->transferred, 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 ->write_iter() returned\nthat it had written more than it was asked to.","cvss_v4":null,"cvss_v3":{"version":"3.1","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","score":7.8},"cwes":["CWE-787"],"references":["https://git.kernel.org/stable/c/387164a2b97e1f5404c6d0049a7409bac7d2bc5b","https://git.kernel.org/stable/c/a3de58b12ce074ec05b8741fa28d62ccb1070468","https://git.kernel.org/stable/c/f08c80af3c9a9849cd178b4843b7c01d103506a1"],"products":["linux:linux_kernel"],"source":"nvd","synced_at":"2026-10-21T03:43:09.190223697+00:00"},"epss":{"cve":"CVE-2025-39723","score":0.00233,"percentile":0.14088,"date":"2026-10-25"},"kev":null,"osv":[],"attribution":["This product uses the NVD API but is not endorsed or certified by the NVD.","EPSS scores: FIRST Exploit Prediction Scoring System, https://www.first.org/epss","Known exploited vulnerabilities: CISA Known Exploited Vulnerabilities Catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog","Package advisories: OSV (https://osv.dev), from the GitHub Advisory Database, PyPA, Go, RustSec and other ecosystem databases, under CC-BY 4.0 or CC0","CVE records: the CVE Program's CVE List (https://www.cve.org), under its terms of use (https://www.cve.org/Legal/TermsOfUse). CVE is a registered trademark of The MITRE Corporation; this product is not affiliated with the CVE Program."]}