[GRASS-git] [OSGeo/grass] 4047b0: lib/raster3d: fix int overflow in Rast3d_copy_valu...

[Yann Chemin]

  Branch: refs/heads/main
  Home:   https://github.com/OSGeo/grass
  Commit: 4047b0f5334ffc9bf03657f151eeb7c4bf80896d
      https://github.com/OSGeo/grass/commit/4047b0f5334ffc9bf03657f151eeb7c4bf80896d
  Author: Yann Chemin <dr.yann.chemin at gmail.com>
  Date:   2026-09-29 (Tue, 29 Sep 2026)

  Changed paths:
    M lib/raster3d/misc.c

  Log Message:
  -----------
  lib/raster3d: fix int overflow in Rast3d_copy_values byte offset (#7970)

Update misc.c : raster3d: fix int overflow in Rast3d_copy_values byte offset.

eltLength, offsSrc and offsDst are all int, so the byte offset is multiplied in 32-bit arithmetic. G_incr_void_ptr() (lib/gis/alloc.c:182) already takes a size_t, but the product has overflowed before it gets there. In our crash, the element offset was 681 M, which fits in an int. Multiplied by 4 bytes for FCELL it becomes 2.7 G, which overflows, goes negative, and memcpy writes before the buffer.

The minimal fix: widen the multiplication to size_t:

67    src = G_incr_void_ptr(src, (size_t)eltLength * offsSrc);
68    dst = G_incr_void_ptr(dst, (size_t)eltLength * offsDst);

That fixes our case: blocks of up to 2³¹ − 1 cells, which is 8 GiB of FCELL. Line 70 already casts the memcpy length the same way ((size_t)nElts * eltLength), so the fix makes lines 67–68 consistent with the line just below them.
A complete fix for blocks over 2³¹ cells would also need two more changes. Both alter the public API, so they suit a separate PR:
- lib/raster3d/getblock.c:66–67 computes the destination offset (z + dz) * nx * ny + (y + dy) * nx + (x + dx) in int.
- Rast3d_copy_values() takes its offsets as int (the prototype is at include/grass/defs/raster3d.h:173). Both would have to become size_t.



To unsubscribe from these emails, change your notification settings at https://github.com/OSGeo/grass/settings/notifications