hdf5: patch CVE-2026-17574

Details:
https://nvd.nist.gov/vuln/detail/cve-2026-17574

Signed-off-by: Ankur Tyagi <ankur.tyagi85@gmail.com>
Signed-off-by: Anuj Mittal <anuj.mittal@oss.qualcomm.com>
This commit is contained in:
Ankur Tyagi
2026-09-15 07:52:01 +05:30
committed by Anuj Mittal
parent f46990293c
commit 637f437de9
2 changed files with 66 additions and 0 deletions
@@ -0,0 +1,65 @@
From e374b227c277e100d9bfa3b1fe5c0b60cdff6c43 Mon Sep 17 00:00:00 2001
From: tbeu <tbeu@users.noreply.github.com>
Date: Thu, 28 May 2026 17:26:57 +0200
Subject: [PATCH] Validate VL datatype type during decode and check file
pointer in H5T_set_loc (#6395)
H5O__dtype_decode_helper() reads vlen.type from the file without
validation. With corrupted HDF5 files (e.g. from fuzzing), this field
can have an invalid value that is neither H5T_VLEN_SEQUENCE nor
H5T_VLEN_STRING, which later triggers assert(0) in H5T__vlen_set_loc()
(debug builds) or a NULL pointer dereference / SEGV in release builds.
Fix by:
1. Adding a validation check in H5O__dtype_decode_helper() immediately
after reading the vlen.type field, returning an error if the value
is invalid.
2. Adding a NULL file pointer check in H5T_set_loc() before calling
H5T__vlen_set_loc() when loc == H5T_LOC_DISK, so the low-level
assert(file) invariant is never violated.
This fixes the root cause at the decode level where the bad value
enters the system, as requested in review of #6378 and #6385.
Found by OSS-Fuzz via the matio fuzzer (ClusterFuzz testcase
5366895365914624).
(cherry picked from commit 3fa6ed6e9dfeebbc784e21d8c48e31e35a8042bc)
CVE: CVE-2026-17574
Upstream-Status: Backport [https://github.com/HDFGroup/hdf5/commit/3fa6ed6e9dfeebbc784e21d8c48e31e35a8042bc]
Signed-off-by: Ankur Tyagi <ankur.tyagi85@gmail.com>
---
src/H5Odtype.c | 2 ++
src/H5T.c | 5 +++++
2 files changed, 7 insertions(+)
diff --git a/src/H5Odtype.c b/src/H5Odtype.c
index d6405cdb86..6e622f3ebc 100644
--- a/src/H5Odtype.c
+++ b/src/H5Odtype.c
@@ -751,6 +751,8 @@ H5O__dtype_decode_helper(unsigned *ioflags /*in,out*/, const uint8_t **pp, H5T_t
*/
/* Set the type of VL information, either sequence or string */
dt->shared->u.vlen.type = (H5T_vlen_type_t)(flags & 0x0f);
+ if (dt->shared->u.vlen.type != H5T_VLEN_SEQUENCE && dt->shared->u.vlen.type != H5T_VLEN_STRING)
+ HGOTO_ERROR(H5E_DATATYPE, H5E_BADVALUE, FAIL, "invalid VL datatype type");
if (dt->shared->u.vlen.type == H5T_VLEN_STRING) {
dt->shared->u.vlen.pad = (H5T_str_t)((flags >> 4) & 0x0f);
dt->shared->u.vlen.cset = (H5T_cset_t)((flags >> 8) & 0x0f);
diff --git a/src/H5T.c b/src/H5T.c
index 3b2e391a53..e2c9ba9791 100644
--- a/src/H5T.c
+++ b/src/H5T.c
@@ -6953,6 +6953,11 @@ H5T_set_loc(H5T_t *dt, H5VL_object_t *file, H5T_loc_t loc)
ret_value = changed;
} /* end if */
+ /* Validate file pointer for disk-based VL types */
+ if (loc == H5T_LOC_DISK && NULL == file)
+ HGOTO_ERROR(H5E_DATATYPE, H5E_BADVALUE, FAIL,
+ "NULL file pointer for disk-based VL datatype");
+
/* Mark this VL sequence */
if ((changed = H5T__vlen_set_loc(dt, file, loc)) < 0)
HGOTO_ERROR(H5E_DATATYPE, H5E_CANTINIT, FAIL, "Unable to set VL location");
@@ -20,6 +20,7 @@ SRC_URI = "https://support.hdfgroup.org/releases/hdf5/v2_0/v2_0_0/downloads/${BP
file://CVE-2026-26197.patch \
file://CVE-2026-17572.patch \
file://CVE-2026-17573.patch \
file://CVE-2026-17574.patch \
"
SRC_URI[sha256sum] = "f4c2edc5668fb846627182708dbe1e16c60c467e63177a75b0b9f12c19d7efed"