-
Type:
Bug
-
Resolution: Fixed
-
Priority:
P3
-
Affects Version/s: 17, 19, 20
-
Component/s: hotspot
-
b24
There are several issues with os::realloc():
1) If realloc(3) fails, the original block will be left untouched. That is fine, and the caller may expect this continue to use it, and later hand it to os::free(). But NMT has marked the original block as dead already. This will cause a subsequent os::free() or os::realloc() to trigger a false block integrity error. So, if realloc(3) fails, we need to revive the NMT header and re-account the original block.
2) If handed in very large sizes, the size may overflow if the NMT header is added. The result would be that the VM reallocates to a much smaller buffer which would cause subsequent memory corruption if the caller were to use the buffer (same as JDK-8286519, but for realloc).
3) If os::realloc() enlarges a buffer, the newly added memory should be zapped with uinitBlockPad as we do for os::malloc(). Of course we only can do this if NMT is enabled, otherwise we won't know the original block size.
1) If realloc(3) fails, the original block will be left untouched. That is fine, and the caller may expect this continue to use it, and later hand it to os::free(). But NMT has marked the original block as dead already. This will cause a subsequent os::free() or os::realloc() to trigger a false block integrity error. So, if realloc(3) fails, we need to revive the NMT header and re-account the original block.
2) If handed in very large sizes, the size may overflow if the NMT header is added. The result would be that the VM reallocates to a much smaller buffer which would cause subsequent memory corruption if the caller were to use the buffer (same as JDK-8286519, but for realloc).
3) If os::realloc() enlarges a buffer, the newly added memory should be zapped with uinitBlockPad as we do for os::malloc(). Of course we only can do this if NMT is enabled, otherwise we won't know the original block size.
