Repository navigation
Conversation
ZSTD_copyDCtx() memcpy'd the source DCtx's customMem over the destination's one. When both contexts were created with different allocators, ZSTD_freeDCtx() then released the destination context (and its resources) with the source's callbacks, producing an allocator mismatch (invalid free / crash) since the destination context itself was allocated with its own allocator. Save dstDCtx->customMem before the memcpy and restore it afterwards, so the copy preserves the destination's allocator as freeDCtx relies on it. ZSTD_copyCCtx_internal() has the same overwrite pattern but the workspace allocations inside ZSTD_resetCCtx_internal() reuse the overwritten customMem consistently for every resource they allocate; only the destination context struct itself stays allocated with the original allocator, which is not addressable from this function. Flagged in the API docs comment instead. Add a fuzzer regression test: copy a DCtx created with a flagging custom allocator into a default-created one, free the destination, and require that the source's customFree was never called for it. Fixes facebook#4830 Signed-off-by: masachika shiotsuka <n2655f@labs.aizu.ac.jp>
|
Hi @tasodoufu! Thank you for your pull request and welcome to our community. Action RequiredIn order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you. ProcessIn order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA. Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks! |
AI disclosure: this change (including the reproducer, fix and test) was found, implemented and verified with the help of an AI agent, as permitted by the contribution guidelines.
Reproduction
ZSTD_copyDCtx()overwrites the destination context'sZSTD_customMemwith the source's one (it is part of the memcpy'd prefix, offset 0 toinBuff). When the two contexts were created with different allocators,ZSTD_freeDCtx(dst)then releases the destination context — which was allocated with its own allocator — using the source's callbacks.With a custom allocator whose free is not plain
free()-compatible (e.g. an offset-pointer scheme like Rust bindings often use, or any counter-equipped allocator), this is an invalid free. Standalone reproducer (built fromdev= 49cf517,ZSTD_DISABLE_ASM=1):free(): invalid pointer, abort (exit 134).The new fuzzer unit test detects the same mismatch without faulting: it copies a DCtx created with a flagging allocator into a default-created one and requires that the source's
customFreewas never invoked for the destination's release.Root cause
lib/decompress/zstd_decompress.c,ZSTD_copyDCtx():customMemsits inside the copied prefix, so the destination loses its own allocator.ZSTD_freeDCtx()(ZSTD_customFree(dctx, cMem)/ workspace release) then uses mismatched callbacks.ZSTD_copyCCtx_internal()(lib/compress/zstd_compress.c) has the same overwrite, but there the subsequentZSTD_resetCCtx_internal()allocates all workspace resources with the overwrittencustomMem, so their free path stays self-consistent; only the destinationZSTD_CCtxstruct itself remains allocated with the original allocator and is freed with the — now overwritten —cctx->customMem(ZSTD_freeCCtx→ZSTD_customFree(cctx, cctx->customMem)when the struct is not workspace-owned). That residual asymmetry is not reachable fromZSTD_copyCCtx_internal()itself without breaking a documented behavior, so this PR keeps its scope toZSTD_copyDCtx()and leaves thecopyCCtxpattern untouched (no header/API change, no are-QA-semantics change). If maintainers prefer a symmetriccustomMem-preserving change there too, I'm happy to extend.Fix
Save
dstDCtx->customMembefore the memcpy and restore it afterwards (6 lines incl. comments), soZSTD_copyDCtx()preserves the destination's allocator, asZSTD_freeDCtx()relies on it.Test
tests/fuzzer.c(basicUnitTests, right after theZSTD_createDCtx_advancedtest): fails on unpatcheddev, passes with the fix;verified the failure pre-push: with the library fix stashed,
./fuzzer -i0 -T1sexits 1 with onlytest 76 : ZSTD_copyDCtx keeps the destination's allocatorfailing; with the fix it passes and the run exits 0 (17 fuzzer tests completed).git diff --checkclean;zstd_decompress.crecompiled warning-free under-Werror -Wall -Wextra -Wcast-qual -Wcast-align -Wshadow -Wstrict-aliasing=1 -Wdeclaration-after-statement -Wstrict-prototypes -Wundef -Wpointer-arith -Wformat=2(ZSTD_MULTITHREAD).Not verified
make testsuite was not run here (only the fuzzer driver-i0 -T1s, which coversbasicUnitTests+ 17 earlier fuzzer test groups); the rest of the suite does not exercise vs-mismatched allocator copies beyond the covered paths, but this is not machine-verified.ZSTD_copyCCtxallocator-mismatch residual asymmetry (described above) left as-is.