netcdf-c/libhdf5
Even Rouault 77ffbce43b
NC4_get_vars(): fix out-of-bounds write with unlimited dimension
This fixes an issue hit by GDAL, and that is found in netcdf 4.6.3
and 4.7.0

git bisect pointed the problem to have started with

```
77ab979c5f is the first bad commit
commit 77ab979c5f
Author: Ed Hartnett <edwardjameshartnett@gmail.com>
Date:   Sat Jun 16 09:58:48 2018 -0600

    using get_vars but not put_vars

:040000 040000 8611e77aae fc9ffd1d13 M	libsrc4
```

where nc_get_vara_double() started using nc4_get_vars() underneath.

It turns out that nc4_get_vars() was buggy in the situation exercised by GDAL.

This can be reproduced with the following simple test case:

```

int main()
{
    int status;
    int cdfid = -1;
    int first_dim;
    int varid;
    int other_var;
    size_t anStart[NC_MAX_DIMS];
    size_t anCount[NC_MAX_DIMS];
    double* val = (double*)calloc(3, sizeof(double));

    status = nc_create("foo.nc", NC_NETCDF4, &cdfid);
    assert( status == NC_NOERR );

    status = nc_def_dim(cdfid, "unlimited_dim", NC_UNLIMITED, &first_dim);
    assert( status == NC_NOERR );

    status = nc_def_var(cdfid, "my_var", NC_DOUBLE, 1, &first_dim, &varid);
    assert( status == NC_NOERR );

    status = nc_def_var(cdfid, "other_var", NC_DOUBLE, 1, &first_dim, &other_var);
    assert( status == NC_NOERR );

    status = nc_enddef(cdfid);
    assert( status == NC_NOERR );

    /* Write 3 elements to set the size of the unlimited dim to 3 */
    anStart[0] = 0;
    anCount[0] = 3;
    status = nc_put_vara_double(cdfid, other_var, anStart, anCount, val);
    assert( status == NC_NOERR );

    /* Read 2 elements starting with index=1 */
    anStart[0] = 1;
    anCount[0] = 2;
    status = nc_get_vara_double(cdfid, varid, anStart, anCount, val);
    assert( status == NC_NOERR );

    status = nc_close(cdfid);
    assert( status == NC_NOERR );

    free(val);

    return 0;
}
```

Running it under Valgrind without this patch leads to
```
==19637==
==19637== Invalid write of size 8
==19637==    at 0x4C326CB: memcpy@@GLIBC_2.14 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==19637==    by 0x4EDBE3D: NC4_get_vars (hdf5var.c:2131)
==19637==    by 0x4EDA24C: NC4_get_vara (hdf5var.c:1342)
==19637==    by 0x4E68878: NC_get_vara (dvarget.c:104)
==19637==    by 0x4E69FDB: nc_get_vara_double (dvarget.c:815)
==19637==    by 0x400C08: main (in /home/even/netcdf-c/build/test)
==19637==  Address 0xb70e3e8 is 8 bytes before a block of size 24 alloc'd
==19637==    at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==19637==    by 0x4009E8: main (in /home/even/netcdf-c/build/test)
==19637==
```
2019-07-18 01:25:21 +02:00
..
CMakeLists.txt Master merge, conflict resolution, cleanup 2019-02-24 16:54:13 -07:00
H5FDhttp.c typo5 2019-01-02 21:37:31 -07:00
H5FDhttp.h Provide byte-range reading of remote datasets 2019-01-01 18:27:36 -07:00
hdf5attr.c Simplify libhdf5/nc5info.c to move to lazy parsing 2019-03-09 20:35:57 -07:00
hdf5cache.c cleanup of whitespace in HDF5 directory 2019-02-19 05:17:47 -07:00
hdf5create.c Merge pull request #1379 from Unidata/threads_part1.dmh 2019-05-02 10:47:46 -06:00
hdf5dim.c added comment describing netcdf-4 behavior in data mode dim renames with longer names 2019-02-25 06:36:39 -07:00
hdf5dispatch.c Centralize calls to curl_global_init and curl_global_cleanup 2019-05-03 13:22:54 -06:00
hdf5file.c For some reason, the code for this was incorrect. 2019-04-18 14:23:20 -06:00
hdf5grp.c cleanup of whitespace in HDF5 directory 2019-02-19 05:18:02 -07:00
hdf5internal.c cleanup of whitespace in HDF5 directory 2019-02-19 05:18:25 -07:00
hdf5open.c Merge pull request #1379 from Unidata/threads_part1.dmh 2019-05-02 10:47:46 -06:00
hdf5type.c cleanup of whitespace in HDF5 directory 2019-02-19 05:18:25 -07:00
hdf5var.c NC4_get_vars(): fix out-of-bounds write with unlimited dimension 2019-07-18 01:25:21 +02:00
Makefile.am Updated call to NC4_read_provenance. 2019-04-18 10:53:16 -06:00
nc4hdf.c Allow in-line definition of filters 2019-03-21 11:33:27 -06:00
nc4info.c For some reason, the code for this was incorrect. 2019-04-18 14:23:20 -06:00
nc4mem.c
nc4memcb.c Thread safety: step 1: cleanup 2019-03-30 14:06:20 -06:00