<html><body><div dir="auto">Source: netcdf<br>Version: 1:4.10.1-1<br>Severity: important<br>Tags: security upstream patch<br>X-Debbugs-Cc: <a href="mailto:team@security.debian.org">team@security.debian.org</a><br><br>Hi,<br><br>The security tracker lists CVE-2026-86095 as unfixed for netcdf, but<br>there is no Debian bug for it yet, so here is one.<br><br>CVE-2026-86095: "Unidata netcdf-c through 4.10.1 contains an<br>out-of-bounds write vulnerability in NC4_HDF5_inq_attname() that copies<br>HDF5 attribute names into a fixed 256-byte buffer without length<br>validation."<br><br>Upstream issue (open, no fix on main yet):<br>  <a href="https://www.google.com/url?q=https://github.com/Unidata/netcdf-c/issues/3463&source=gmail&ust=1793796591657000&sa=E">https://www.google.com/url?q=https://github.com/Unidata/netcdf-c/issues/3463&source=gmail&ust=1793796591657000&sa=E</a><br><br>Root cause: NC4_HDF5_inq_attname() (libhdf5/hdf5attr.c) does<br>strcpy(name, att-><a href="https://www.google.com/url?q=http://hdr.name&source=gmail&ust=1793796591657000&sa=E">https://www.google.com/url?q=http://hdr.name&source=gmail&ust=1793796591657000&sa=E</a>), and callers size "name" as<br>NC_MAX_NAME + 1. When netCDF writes attributes, it checks the length<br>against NC_MAX_NAME (hdf5attr.c, "strlen(name) > NC_MAX_NAME"). But when<br>it opens an HDF5 file, att_read_callbk() in libhdf5/hdf5open.c adds<br>every attribute name from the file without a length check. So an HDF5<br>file that netCDF did not write can carry longer names.<br><br>There are two possible fixes:<br><br>a) Other distributions truncate at the copy site. SUSE's<br>   "Fix-a-potential-write-past-end-of-a-fixed-size-buffer.patch" and<br>   OSGeo4W's patch (referenced from the upstream issue) replace the<br>   strcpy with strncpy(name, att-><a href="https://www.google.com/url?q=http://hdr.name&source=gmail&ust=1793796591657000&sa=E">https://www.google.com/url?q=http://hdr.name&source=gmail&ust=1793796591657000&sa=E</a>, NC_MAX_NAME - 1) plus a<br>   terminator.<br><br>b) The attached patch rejects such names at read time instead: in<br>   att_read_callbk() it skips attributes whose names are longer than<br>   NC_MAX_NAME, in the same way the function already skips reserved<br>   attribute names. That way a name netCDF could never have written is<br>   never stored, so no other path that copies attribute names into an<br>   NC_MAX_NAME+1 buffer can overflow either. The trade-off is that such<br>   attributes are not visible through the netCDF API. With (a) they are<br>   visible, but under a truncated name that may not round-trip through<br>   nc_get_att by name. The only other caller of nc4_att_list_add() in<br>   libhdf5 is the write path, which already enforces NC_MAX_NAME.<br><br>Either is fine with me; please pick whichever you prefer, or follow<br>upstream once they decide.<br><br>Testing of (b), on upstream netcdf-c 4.10.1 (amd64, sid, HDF5 from<br>libhdf5-dev, --disable-shared --disable-dap --disable-byterange<br>--disable-nczarr --disable-plugins; built and tested as an unprivileged<br>user):<br>  - both trees build; no warnings in hdf5open.c<br>  - make check, unpatched 4.10.1: 201 tests, PASS 201, FAIL 0<br>  - make check, patched 4.10.1:   201 tests, PASS 201, FAIL 0<br>I did not construct an HDF5 file with an oversized attribute name, so<br>the overflow itself was not reproduced here. The test-suite result only<br>shows that the patch causes no regressions.<br><br>The patch applies to 4.10.1 as is; att_read_callbk() is identical on<br>current upstream main.<br><br>Regards</div></body></html>