Skip to content

Conversation

@bmribler
Copy link
Collaborator

@bmribler bmribler commented Sep 16, 2025

An image size was corrupted and decoded as 0 resulting in a NULL image buffer, which caused a NULL pointer dereference when the image being copied to the buffer. This PR adds the image size check.

Fixes #5384


Important

Fix CVE-2025-2926 by adding image size check in H5O__cache_chk_get_initial_load_size() to prevent NULL pointer dereference.

This description was created by Ellipsis for f9a8267. You can customize this summary. It will automatically update as commits are pushed.

@bmribler
Copy link
Collaborator Author

Umm, FYI, this PR only has the changes in H5Centry.c and RELEASE.txt. Sorry!

===================================
Library
-------
- Fixed CVE 2025 2926
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should use hyphens in the name, like other CVE issues

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I don't know how that happened. I always have hyphens... Thanks, Dana.

src/H5Cimage.c Outdated
if (H5C__decode_cache_image_header(f, cache_ptr, &p, image_len + 1) < 0)
HGOTO_ERROR(H5E_CACHE, H5E_CANTDECODE, FAIL, "cache image header decode failed");
assert((size_t)(p - (uint8_t *)cache_ptr->image_buffer) < cache_ptr->image_len);
assert((size_t)(p - (uint8_t *)cache_ptr->image_buffer) < image_len);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not make this a real error check instead of an assert?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If H5C__decode_cache_image_header checks for overflow an assert is appropriate here. And if it doesn't, it should.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change was merged into this PR by accident and that was fixed now. I'll check out about H5C__decode_cache_image_header() and create another PR instead.

Copy link
Collaborator Author

@bmribler bmribler Sep 27, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR #5884 adds the missing overflow checks, @fortnern.

@derobins derobins changed the title Fix CVE 2025 2926 Fix CVE-2025-2926 Sep 17, 2025
mattjala
mattjala previously approved these changes Sep 18, 2025
@nbagha1 nbagha1 moved this from To be triaged to Scheduled/On-Deck in HDF5 - TRIAGE & TRACK Sep 23, 2025
src/H5Centry.c Outdated
if (type->get_initial_load_size(udata, &len) < 0)
HGOTO_ERROR(H5E_CACHE, H5E_CANTGET, NULL, "can't retrieve image size");
assert(len > 0);
if (len == 0)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems to me this should really be checked in the callbacks, and left as an assert here.

Copy link
Member

@fortnern fortnern Sep 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you know why the callback is returning len=0 without returning an error?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I fixed it and push the change soon

An image size was corrupted and decoded as 0 resulting in a NULL image buffer,
which caused a NULL pointer dereference when the image being copied to the buffer.
The invalid image size was caught in the PR #5710.  This change catches right
before the copying.

Fixes GH issue #5384
Copy link
Member

@fortnern fortnern left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See questions about get_initial_load_size returning len==0

@github-project-automation github-project-automation bot moved this from Scheduled/On-Deck to In progress in HDF5 - TRIAGE & TRACK Sep 24, 2025
@bmribler bmribler requested a review from fortnern September 25, 2025 15:27
@bmribler bmribler requested a review from mattjala September 25, 2025 15:27
@fortnern
Copy link
Member

I think we still need to get to the bottom of this. I did some digging and it looks like the size in the udata comes from a continuation message, but H5O__cont_decode() checks for size == 0. Can you try to figure out how it's getting past that check?

@bmribler
Copy link
Collaborator Author

bmribler commented Sep 27, 2025

@fortnern I believe this commit took care of the len=0 issue. Although, I'm not exactly sure how that commit is not listed in the changed files of #5841...

@fortnern
Copy link
Member

@fortnern I believe this commit took care of the len=0 issue. Although, I'm not exactly sure how that commit is not listed in the changed files of #5841...

This check isn't as close to the file as it could be. As I mentioned previously, the udata->size in that function should come from H5O__cont_decode(), which already has a check for size == 0. Can you try to figure out how that was bypassed?

@bmribler
Copy link
Collaborator Author

bmribler commented Oct 16, 2025

@fortnern I believe this commit took care of the len=0 issue. Although, I'm not exactly sure how that commit is not listed in the changed files of #5841...

This check isn't as close to the file as it could be. As I mentioned previously, the udata->size in that function should come from H5O__cont_decode(), which already has a check for size == 0. Can you try to figure out how that was bypassed?

Oh, it did catch:
H5Ocont.c line 104 in H5O__cont_decode(): invalid continuation chunk size (0)

I thought we wanted additional checking too.

@fortnern
Copy link
Member

So the CVE is already fixed without this PR? I think the check in this PR should just be an assertion (unless there's some case where we really can't catch it before here)

@fortnern
Copy link
Member

We should only do enough non-assert checking as is necessary to guarantee a consistent internal state. Additional checking should be in the form of assertions.

@bmribler
Copy link
Collaborator Author

@fortnern The assert was already put back in the commit I mentioned in #5841 (comment). Sorry, I forgot that I did.

@lrknox lrknox added Component - C Library Core C library issues (usually in the src directory) Component - Documentation Doxygen, markdown, etc. labels Oct 24, 2025
@fortnern
Copy link
Member

fortnern commented Oct 28, 2025

There is no assert in H5O__cache_chk_get_initial_load_size() currently and this PR adds an error check instead of an assert. Is there a reason you think this should not be an assert instead?

Copy link
Member

@fortnern fortnern left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please change this to an assertion or explain why it needs to be an error check. My understanding is the CVE was fixed by a different PR that added the check in the appropriate place, correct? Did that PR add a Changelog.md note? If so, no need for this one.

assert(udata);
assert(udata->oh);
assert(image_len);
assert(udata->size);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The runtime check for udata->size==0 was removed and replaced with an assert. In production builds, asserts may be disabled, so a corrupted image size of 0 won’t be caught, possibly leading to a NULL pointer dereference. Please retain a runtime error check (e.g. using HGOTO_ERROR) to ensure the image size is nonzero.

@bmribler bmribler requested a review from fortnern October 29, 2025 05:54
Fixed a heap buffer overflow in H5FS__sinfo_serialize_node_cb() by discarding file free space sections from the file free space manager when they are found to be invalid. Specifically crafted HDF5 files can result in an attempt to insert duplicate or overlapping file free space sections into a file free space manager, later resulting in a buffer overflow when the same free space section is serialized to the file multiple times.

Fixes GitHub issue #5577

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I don't know how this entry got into my commit... I hope I didn't cause anything bad.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Component - C Library Core C library issues (usually in the src directory) Component - Documentation Doxygen, markdown, etc.

Projects

Status: In progress

Development

Successfully merging this pull request may close these issues.

NULL Pointer Dereference in H5O__cache_chk_serialize

7 participants