-
-
Notifications
You must be signed in to change notification settings - Fork 270
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix vuln OSV-2023-77 #5210
Fix vuln OSV-2023-77 #5210
Conversation
src/H5Cimage.c
Outdated
@@ -1287,6 +1287,10 @@ H5C__decode_cache_image_header(const H5F_t *f, H5C_t *cache_ptr, const uint8_t * | |||
/* Point to buffer to decode */ | |||
p = *buf; | |||
|
|||
/* Ensure buffer has enough data for signature comparison */ | |||
if ((size_t)(*buf + H5C__MDCI_BLOCK_SIGNATURE_LEN - p) > cache_ptr->image_len) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The logic is generally fine, but a couple of issues here:
- This should really use the
H5_IS_BUFFER_OVERFLOW
macro from H5private.h to be consistent with other decode routines throughout the library - This is a yet-to-be-fixed case where the size of
buf
should really be passed in as a parameter to the function rather than relying on it from elsewhere. For example, the size ofbuf
here is actuallycache_ptr->image_len + 1
, which doesn't really make a difference for this case, but it's easy to see how relying oncache_ptr->image_len
here can cause trouble.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The logic is generally fine, but a couple of issues here:
- This should really use the
H5_IS_BUFFER_OVERFLOW
macro from H5private.h to be consistent with other decode routines throughout the library- This is a yet-to-be-fixed case where the size of
buf
should really be passed in as a parameter to the function rather than relying on it from elsewhere. For example, the size ofbuf
here is actuallycache_ptr->image_len + 1
, which doesn't really make a difference for this case, but it's easy to see how relying oncache_ptr->image_len
here can cause trouble.
Thanks for your suggestion, I updated using macros for checking.
But for the second point, all arguments passed in this function so far, buf, seem to be cache_ptr->image_buffer
, is there any possibility of expansion in the future?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry I should have been more clear; what I meant was that we should update H5C__decode_cache_image_header()
with an extra size parameter for the size of buf
and then use that for overflow calculations rather than cache_ptr->image_len
. This is similar to other decode routines where the functions have both a buffer and size of the buffer parameter. The calculations should essentially be the same since cache_ptr->image_len + 1
is what the callers will be passing in for the size parameter, but it should be a bit safer than relying on the size from the cache_ptr
structure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, sorry, I understand, sounds good, I have added the size parameter.
add an extra size paramete in H5C__decode_cache_image_header()
src/H5Cimage.c
Outdated
@@ -1287,6 +1288,10 @@ H5C__decode_cache_image_header(const H5F_t *f, H5C_t *cache_ptr, const uint8_t * | |||
/* Point to buffer to decode */ | |||
p = *buf; | |||
|
|||
/* Ensure buffer has enough data for signature comparison */ | |||
if (H5_IS_BUFFER_OVERFLOW(p, H5C__MDCI_BLOCK_SIGNATURE_LEN, *buf + buf_size)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be *buf + buf_size - 1
(the last valid byte in *buf), but otherwise the changes look good; thanks for this fix!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a small fix needed
@@ -2386,7 +2391,7 @@ H5C__reconstruct_cache_contents(H5F_t *f, H5C_t *cache_ptr) | |||
|
|||
/* Decode metadata cache image header */ | |||
p = (uint8_t *)cache_ptr->image_buffer; | |||
if (H5C__decode_cache_image_header(f, cache_ptr, &p) < 0) | |||
if (H5C__decode_cache_image_header(f, cache_ptr, &p, cache_ptr->image_len + 1) < 0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are you adding '+1' here and then '-1' in the code in H5C__decode_cache_image_header?
I believe that you can remove both.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The +1 is the real total size of the buffer, so it makes sense to pass it here as that's what the function should expect to receive. The -1 in the function is just because of how the H5_IS_BUFFER_OVERFLOW
macro is implemented. They could both be removed, but I think that's making things a lot less clear and introducing the potential for trouble.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The image_len is not the actual size of the image_buffer?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if the extra byte allocated for the cache image buffer is necessary (see H5Cimage.c ~line 622), but if that +1 was removed then this becomes simple
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree - those '+1' in the allocations are incorrect. Especially since we are reading, writing, and bcasting only 'image_len' everywhere in the code.
Also, I believe this line in H5C__decode_cache_image_header? "if (cache_ptr->image_data_len != cache_ptr->image_len)" should us 'buf_size' instead of 'cache_ptr->image_len' |
With the extra byte allocated for the cache image buffer, I'm think that comparing against |
Sure, but the +1 should be removed, per our other discussion. |
I'd be happy to make those changes in a separate PR since I think it's mostly orthogonal and even though I can't imagine removing that extra byte will cause problems, I like to prepare for the worst. |
Seems like extra work, but I'm fine with that. |
[Warning] This PR is generated by AI
Pull Request Description
1. PR Title: Fix for Heap-Buffer-Overflow Vulnerability in HDF5 - OSV-2023-77
2. PR Description:
H5C__decode_cache_image_header
function. Specifically, it tried to read 4 bytes from a 1-byte allocated buffer, resulting in an out-of-bounds memory access.memcmp
operation. This ensures that the buffer has sufficient data for the signature comparison. If the buffer size is insufficient, the function exits gracefully with an appropriate error message, preventing the overflow.3. Sanitizer Report Summary:
The sanitizer detected a heap-buffer-overflow error. Specifically:
H5C__decode_cache_image_header
function at/src/H5Cimage.c:1291:9
, called by several other functions leading up to theH5Dopen2
function.H5C__load_cache_image
at/src/H5Cimage.c:619:48
.4. Full Sanitizer Report:
5. Files Modified:
src/H5Cimage.c
6. Patch Validation:
The patch has been validated using the provided PoC. The vulnerability identified in the sanitizer report has been resolved, and no new issues were introduced.
7. Links:
-Original Vulnerability Report
-PoC