CVE Catalog

CVE-2025-39723

HighCVSS 7.1
Published: Updated: Translated: NVD NIST

Exploitation Probability (EPSS)

Low risk
0.21%

12th percentile - higher than 12% of all known CVEs

Summary

In the Linux kernel netfs subsystem, a bug was found in unbuffered write error handling. When all subrequests in an unbuffered write stream fail, the stream->transferred variable is not updated and retains its initial LONG_MAX value. This causes ->write_iter() to return LONG_MAX instead of an error, potentially leading to a kernel oops when cleaning pipe buffers.

Risk Assessment

The organization is at risk of a kernel panic during file writes via CIFS with caching disabled when disk space runs out. This can lead to data loss and service disruption.

Recommendation

Immediately update the Linux kernel to a version containing the fix (commit adding a validity flag for stream->transferred and initializing it to zero). Apply the security patch for production systems.

Other vulnerabilities in Linux kernel

See all
Original NVD description (English source)

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.

Vulnerability data from NVD (NIST) · CISA KEV · EPSS