{ "schema_version": "1.6.1", "id": "RPI-CVE-2025-39723", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2025-39723" ], "published": "2025-09-05T17:22:05Z", "summary": "netfs: Fix unbuffered write error handling", "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'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.", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.12.20-1+rpt1~bpo12+1", "1:6.12.25-1+rpt1", "1:6.12.34-1+rpt1~bookworm" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.12.20+rpt-rpi-2712", "binary_version": "1:6.12.20-1+rpt1~bpo12+1" }, { "binary_name": "linux-image-6.12.20+rpt-rpi-v6", "binary_version": "1:6.12.20-1+rpt1~bpo12+1" }, { "binary_name": "linux-image-6.12.20+rpt-rpi-v7", "binary_version": "1:6.12.20-1+rpt1~bpo12+1" }, { "binary_name": "linux-image-6.12.20+rpt-rpi-v7l", "binary_version": "1:6.12.20-1+rpt1~bpo12+1" }, { "binary_name": "linux-image-6.12.20+rpt-rpi-v8", "binary_version": "1:6.12.20-1+rpt1~bpo12+1" }, { "binary_name": "linux-image-6.12.25+rpt-rpi-2712", "binary_version": "1:6.12.25-1+rpt1" }, { "binary_name": "linux-image-6.12.25+rpt-rpi-v6", "binary_version": "1:6.12.25-1+rpt1" }, { "binary_name": "linux-image-6.12.25+rpt-rpi-v7", "binary_version": "1:6.12.25-1+rpt1" }, { "binary_name": "linux-image-6.12.25+rpt-rpi-v7l", "binary_version": "1:6.12.25-1+rpt1" }, { "binary_name": "linux-image-6.12.25+rpt-rpi-v8", "binary_version": "1:6.12.25-1+rpt1" }, { "binary_name": "linux-image-6.12.34+rpt-rpi-2712", "binary_version": "1:6.12.34-1+rpt1~bookworm" }, { "binary_name": "linux-image-6.12.34+rpt-rpi-v6", "binary_version": "1:6.12.34-1+rpt1~bookworm" }, { "binary_name": "linux-image-6.12.34+rpt-rpi-v7", "binary_version": "1:6.12.34-1+rpt1~bookworm" }, { "binary_name": "linux-image-6.12.34+rpt-rpi-v7l", "binary_version": "1:6.12.34-1+rpt1~bookworm" }, { "binary_name": "linux-image-6.12.34+rpt-rpi-v8", "binary_version": "1:6.12.34-1+rpt1~bookworm" }, { "binary_name": "linux-image-6.12.34+rpt-rpi-v8-rt", "binary_version": "1:6.12.34-1+rpt1~bookworm" } ] }, "database_specific": { "per_version": { "1:6.12.20-1+rpt1~bpo12+1": { "linux_commit": "cd231d4775b14f228606c09f219b48308f6ab3aa", "upstream_version": "6.12.20", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.12.44" }, "1:6.12.25-1+rpt1": { "linux_commit": "3dd2c2c507c271d411fab2e82a2b3b7e0b6d3f16", "upstream_version": "6.12.25", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.12.44" }, "1:6.12.34-1+rpt1~bookworm": { "linux_commit": "8f77e03530f65209a377d25023e912b288e039cd", "upstream_version": "6.12.34", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.12.44" } } } }, { "package": { "ecosystem": "Raspberry Pi OS:13", "name": "linux" }, "versions": [ "1:6.12.19-1+rpt1~bpo12+1", "1:6.12.19-1+rpt1", "1:6.12.20-1+rpt1", "1:6.12.25-1+rpt1+trixie", "1:6.12.34-1+rpt1" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.12.19+rpt-rpi-2712", "binary_version": "1:6.12.19-1+rpt1~bpo12+1" }, { "binary_name": "linux-image-6.12.19+rpt-rpi-v6", "binary_version": "1:6.12.19-1+rpt1~bpo12+1" }, { "binary_name": "linux-image-6.12.19+rpt-rpi-v7", "binary_version": "1:6.12.19-1+rpt1~bpo12+1" }, { "binary_name": "linux-image-6.12.19+rpt-rpi-v7l", "binary_version": "1:6.12.19-1+rpt1~bpo12+1" }, { "binary_name": "linux-image-6.12.19+rpt-rpi-v8", "binary_version": "1:6.12.19-1+rpt1~bpo12+1" }, { "binary_name": "linux-image-6.12.19+rpt-rpi-2712", "binary_version": "1:6.12.19-1+rpt1" }, { "binary_name": "linux-image-6.12.19+rpt-rpi-v6", "binary_version": "1:6.12.19-1+rpt1" }, { "binary_name": "linux-image-6.12.19+rpt-rpi-v7", "binary_version": "1:6.12.19-1+rpt1" }, { "binary_name": "linux-image-6.12.19+rpt-rpi-v7l", "binary_version": "1:6.12.19-1+rpt1" }, { "binary_name": "linux-image-6.12.19+rpt-rpi-v8", "binary_version": "1:6.12.19-1+rpt1" }, { "binary_name": "linux-image-6.12.20+rpt-rpi-2712", "binary_version": "1:6.12.20-1+rpt1" }, { "binary_name": "linux-image-6.12.20+rpt-rpi-v6", "binary_version": "1:6.12.20-1+rpt1" }, { "binary_name": "linux-image-6.12.20+rpt-rpi-v7", "binary_version": "1:6.12.20-1+rpt1" }, { "binary_name": "linux-image-6.12.20+rpt-rpi-v7l", "binary_version": "1:6.12.20-1+rpt1" }, { "binary_name": "linux-image-6.12.20+rpt-rpi-v8", "binary_version": "1:6.12.20-1+rpt1" }, { "binary_name": "linux-image-6.12.25+rpt-rpi-2712", "binary_version": "1:6.12.25-1+rpt1+trixie" }, { "binary_name": "linux-image-6.12.25+rpt-rpi-v6", "binary_version": "1:6.12.25-1+rpt1+trixie" }, { "binary_name": "linux-image-6.12.25+rpt-rpi-v7", "binary_version": "1:6.12.25-1+rpt1+trixie" }, { "binary_name": "linux-image-6.12.25+rpt-rpi-v8", "binary_version": "1:6.12.25-1+rpt1+trixie" }, { "binary_name": "linux-image-6.12.25+rpt-rpi-v8-rt", "binary_version": "1:6.12.25-1+rpt1+trixie" }, { "binary_name": "linux-image-6.12.34+rpt-rpi-2712", "binary_version": "1:6.12.34-1+rpt1" }, { "binary_name": "linux-image-6.12.34+rpt-rpi-v6", "binary_version": "1:6.12.34-1+rpt1" }, { "binary_name": "linux-image-6.12.34+rpt-rpi-v7", "binary_version": "1:6.12.34-1+rpt1" }, { "binary_name": "linux-image-6.12.34+rpt-rpi-v8", "binary_version": "1:6.12.34-1+rpt1" }, { "binary_name": "linux-image-6.12.34+rpt-rpi-v8-rt", "binary_version": "1:6.12.34-1+rpt1" } ] }, "database_specific": { "per_version": { "1:6.12.19-1+rpt1~bpo12+1": { "linux_commit": "121c2c384b9c2f4790ffb31b2cd25c7d75c8fda0", "upstream_version": "6.12.19", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.12.44" }, "1:6.12.19-1+rpt1": { "linux_commit": "121c2c384b9c2f4790ffb31b2cd25c7d75c8fda0", "upstream_version": "6.12.19", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.12.44" }, "1:6.12.20-1+rpt1": { "linux_commit": "cd231d4775b14f228606c09f219b48308f6ab3aa", "upstream_version": "6.12.20", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.12.44" }, "1:6.12.25-1+rpt1+trixie": { "linux_commit": "3dd2c2c507c271d411fab2e82a2b3b7e0b6d3f16", "upstream_version": "6.12.25", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.12.44" }, "1:6.12.34-1+rpt1": { "linux_commit": "8f77e03530f65209a377d25023e912b288e039cd", "upstream_version": "6.12.34", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.12.44" } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2025-39723" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/f08c80af3c9a9849cd178b4843b7c01d103506a1" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/387164a2b97e1f5404c6d0049a7409bac7d2bc5b" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/a3de58b12ce074ec05b8741fa28d62ccb1070468" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-05T12:19:11Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.1, "cvss_v3_severity": "High", "scenario": "AV:N - The netfs write collector processes write results derived from a remote SMB/9p server's responses, and the arming condition (every write subrequest failing) is entirely under the remote server's control \u2014 a malicious, compromised, or MITM'd file server simply returns STATUS_DISK_FULL/ACCESS_DENIED for the writes and the client kernel oopses. The vulnerable component is bound to the network stack via the cifs/9p transport.\nAC:L - The failure is deterministic: LONG_MAX always exceeds the total bytes held in the pipe, so the splice cleanup loop unconditionally runs past the valid buffers into a slot with NULL ops and faults. No race, no memory-layout dependency, no non-default config (cifs/9p with cache=none, or any O_DIRECT open).\nPR:N - A remote file server needs no credentials or privileges on the victim client to return write errors; in the equivalent local framing an ordinary unprivileged user with write access to the mount triggers it via splice()/cp with no capabilities at all.\nUI:R - The remote attacker cannot initiate the transfer itself \u2014 a client-side process must perform a splice-based write (splice/sendfile/copy_file_range, e.g. a routine `cp` onto the mounted share) for the bogus LONG_MAX return to reach iter_file_splice_write().\nS:U - The corruption and crash are confined to the kernel of the affected host; no VM, IOMMU, or sandbox boundary is crossed.\nC:N - The fault is a NULL function-pointer dereference and pipe-ring state corruption; it yields no read primitive and discloses no kernel or file data to the attacker.\nI:L - ->write_iter() reports 0x7fffffffffffffff bytes written when nothing was written, so applications treat failed writes as successful (silent data loss), netfs_update_i_size() stamps a bogus/overflowed size onto the client inode, and the splice loop destroys unwritten pipe contents and leaves pipe->tail past pipe->head \u2014 limited, non-arbitrary data and metadata corruption.\nA:H - Reliable kernel NULL pointer dereference oops in iter_file_splice_write()/pipe_buf_release(), taken with the pipe mutex held, so the pipe is permanently locked and any other user of it hangs in D state; on panic_on_oops configurations it is a full system panic." } } }