From: Pádraig Brady Date: Sun, 4 Jan 2026 12:45:46 +0000 (+0000) Subject: copy: fix possible infinite loop with SEEK_HOLE X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=bd528f923482223649aa84be7d131e69356149da;p=thirdparty%2Fcoreutils.git copy: fix possible infinite loop with SEEK_HOLE Commit v9.8-95-g4c0cf3864 intended to initialize ext_start to src_pos, as was described at: https://lists.gnu.org/r/coreutils/2025-11/msg00035.html However ipos was inadvertently used, which is only valid the first time through the loop. * src/copy-file-data.c (lseek_copy): Use scan_inference->hole_start only with the initial offset passed to lseek_copy(). * NEWS: Mention the bug fix. Reported at https://github.com/coreutils/coreutils/issues/159 --- diff --git a/NEWS b/NEWS index e3858a8550..ca13267b3c 100644 --- a/NEWS +++ b/NEWS @@ -4,6 +4,11 @@ GNU coreutils NEWS -*- outline -*- ** Bug fixes + cp, install, and mv no longer enter an infinite loop copying sparse files + with SEEK_HOLE. E.g., this was seen on ext4 when copying sparse files with + extents that are being actively updated, and copy offload is not being used. + [bug introduced in coreutils-9.9] + 'date' no longer fails with format directives that return an empty string. [bug introduced in coreutils-9.9] diff --git a/src/copy-file-data.c b/src/copy-file-data.c index 927a6e0480..56b669fe72 100644 --- a/src/copy-file-data.c +++ b/src/copy-file-data.c @@ -338,7 +338,7 @@ lseek_copy (int src_fd, int dest_fd, char **abuf, idx_t buf_size, for (off_t ext_start = scan_inference->ext_start; 0 <= ext_start && ext_start < max_ipos; ) { - off_t ext_end = (ext_start == ipos + off_t ext_end = (ext_start == src_pos ? scan_inference->hole_start : lseek (src_fd, ext_start, SEEK_HOLE)); if (0 <= ext_end)