Fix memory safety bugs in block reading and decompression

[sharadboni]

Summary

Fix three security-relevant bugs that can be triggered by maliciously crafted SST files:

• ReadBlock integer overflow (table/format.cc): handle.size() is a uint64_t read from the SST file. On 32-bit platforms the static_cast<size_t> silently truncates, and on all platforms n + kBlockTrailerSize can wrap to a small value, causing an undersized heap allocation followed by an out-of-bounds write. Added an overflow check before the allocation.

• ZSTD_getFrameContentSize sentinel mishandling (port/port_stdcxx.h): ZSTD_getFrameContentSize returns ZSTD_CONTENTSIZE_UNKNOWN (SIZE_MAX) or ZSTD_CONTENTSIZE_ERROR (SIZE_MAX-1) on failure, but only the value 0 was rejected. Passing SIZE_MAX as the output buffer size to ZSTD_decompressDCtx leads to a massive allocation or undefined behavior. Now both sentinels are properly checked.

• DecodeEntry uint32 overflow (table/block.cc): The bounds check (limit - p) < (non_shared + value_length) performs the addition in uint32_t, which can wrap to a small value and bypass the check, leading to out-of-bounds reads. Split into two sequential checks that cannot overflow.

Test plan

• Verify existing unit tests still pass (make check / cmake --build . --target leveldb_tests)
• Confirm the ReadBlock overflow check rejects a BlockHandle with size() near SIZE_MAX
• Confirm Zstd_GetUncompressedLength returns false for frames that yield ZSTD_CONTENTSIZE_UNKNOWN or ZSTD_CONTENTSIZE_ERROR
• Confirm DecodeEntry returns nullptr when non_shared + value_length would overflow uint32

[sharadboni]

@pwnall Could you review this security fix? It addresses an integer overflow in ReadBlock, Zstd sentinel mishandling, and a uint32 overflow in DecodeEntry that can be triggered via crafted SST files.

[ma7moud48]

ارجMAHMOUD HASSANAL ASFAR بتاريخ ١٦‏/٠٤‏/٢٠٢٦ ١:٤٣ ص، كتب Sharad Boni ***@***.***>:Summary Fix three security-relevant bugs that can be triggered by maliciously crafted SST files: ReadBlock integer overflow (table/format.cc): handle.size() is a uint64_t read from the SST file. On 32-bit platforms the static_cast<size_t> silently truncates, and on all platforms n + kBlockTrailerSize can wrap to a small value, causing an undersized heap allocation followed by an out-of-bounds write. Added an overflow check before the allocation. ZSTD_getFrameContentSize sentinel mishandling (port/port_stdcxx.h): ZSTD_getFrameContentSize returns ZSTD_CONTENTSIZE_UNKNOWN (SIZE_MAX) or ZSTD_CONTENTSIZE_ERROR (SIZE_MAX-1) on failure, but only the value 0 was rejected. Passing SIZE_MAX as the output buffer size to ZSTD_decompressDCtx leads to a massive allocation or undefined behavior. Now both sentinels are properly checked. DecodeEntry uint32 overflow (table/block.cc): The bounds check (limit - p) < (non_shared + value_length) performs the addition in uint32_t, which can wrap to a small value and bypass the check, leading to out-of-bounds reads. Split into two sequential checks that cannot overflow. Test plan Verify existing unit tests still pass (make check / cmake --build . --target leveldb_tests) Confirm the ReadBlock overflow check rejects a BlockHandle with size() near SIZE_MAX Confirm Zstd_GetUncompressedLength returns false for frames that yield ZSTD_CONTENTSIZE_UNKNOWN or ZSTD_CONTENTSIZE_ERROR Confirm DecodeEntry returns nullptr when non_shared + value_length would overflow uint32 You can view, comment on, or merge this pull request online at:   #1320 Commit Summary 6eb1356 Fix memory safety bugs in block reading and decompression File Changes (3 files) M port/port_stdcxx.h (4) M table/block.cc (3) M table/format.cc (7) Patch Links: https://github.com/google/leveldb/pull/1320.patchhttps://github.com/google/leveldb/pull/1320.diff —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>