ZSTD-1.5.2 compress Segmentation fault

[雪舞]

Describe the bug
For some reasons, I'm using a self-compiled zstd-1.5.2 with "make install". And I just wrote a compression example following the example provided in the source code, then got a Segmentation Fault. The following is a code snippet for calling the zstd interface:

int cLevel = 1;
size_t buffInSize = 1000 * 1000;
void* buffIn = 1000 * 1000-byte unsigned char value form unchanging file;
size_t buffOutSize = ZSTD_compressBound(buffInSize);
void* buffOut = malloc(buffOutSize);
for (int i = 0; i < 16; ++i) {
    memset(buffOut, 0, buffOutSize);
    ZSTD_CCtx* cctx = ZSTD_createCCtx();
    size_t const cSize = ZSTD_compressCCtx(cctx, buffOut, buffOutSize, buffIn, buffInSize, cLevel);
    ZSTD_freeCCtx(cctx);
}
free(buffIn);
free(buffOut);

The Segmentation Fault happen randomly in a loop, maybe thirid, fifth, etc. I then tried to use GDB to analyze the call stack of zstd, It is finally located that the crash occurs in FSE_encodeSymbol function(in fse.h).
statePtr->value = stateTable[ (statePtr->value >> nbBitsOut) + symbolTT.deltaFindState];

By comparison with other normally performed compression processes, The cause is that the values of nbBitsOut and symbolTT.deltaFindState are incorrect. As a result, a negative value is obtained after the values are added, and out-of-range occurs. So I went on to trace upwards, and this collapse happened steadily in ZSTD_encodeSequences_body, the first loop call
FSE_encodeSymbol(&blockStream, &stateOffsetBits, ofCode);

Then I noticed that when the program is normal, the value in ml/of/llCodeTable is nbSeq non-zero bytes followed by all 0s; When the program is about to fail, the values in ml/of/llCodeTable are nbSeq non-zero bytes followed by some garbage value.

In the end, I traced backwards to the ZSTD_resetCCtx_internal function. Here, the ZSTD_cwksp_create function applied for memory of neededSpace bytes through ZSTD_customMalloc. and then allocated to llCode, mlCode, and ofCode in zc->seqStore. The memory applied for through malloc is not initialized. As a result, junk values may be randomly allocated. In fact, it is true that when I trace here and find that the values of the three arrays are all 0, the program can complete the compression task normally. When the three arrays happen to be allocated with garbage values, the program crashes.

Based on the preceding debugging process, I changed the method of applying for memory in ZSTD_cwksp_create to ZSTD_customCalloc. Run the program again and there is no problem.

To Reproduce
Steps to reproduce the behavior:
See Decribtion

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots and charts
If applicable, add screenshots and charts to help explain your problem.

Desktop (please complete the following information):

• OS: Linux arm64
• Version: zstd-1.5.2
• Compiler: Gcc 10.3.1
• Flags [e.g. O2]
• Other relevant hardware specs [e.g. Dual-core]
• Build system: make install

Additional context
Add any other context about the problem here.

[Yann Collet]

Thanks for the detailed debugging.

Similar scenarios are supposed to be abundantly tested and fuzzed, so I'm surprised such an obvious bug would be able to pass through. For example, the fact that memory is allocated with malloc, and therefore is not initialized, is not a bug: the initialization process is supposed to be cognizant of this fact, and adjust accordingly, zeroing some memory segments only when necessary.
In the case of the FSE tables, it should not be necessary: we expect these tables to be written to first, during block statistics stage. So even if this memory contains garbage data, it should not matter.

Anyway, another important detail is that v1.5.2 is > 2 years old, and our code base has evolved since.

Would you be able to repeat the experience using the current source code in dev branch ?

[雪舞]

Thanks for the detailed debugging.

Similar scenarios are supposed to be abundantly tested and fuzzed, so I'm surprised such an obvious bug would be able to pass through. For example, the fact that memory is allocated with malloc, and therefore is not initialized, is not a bug: the initialization process is supposed to be cognizant of this fact, and adjust accordingly, zeroing some memory segments only when necessary. In the case of the FSE tables, it should not be necessary: we expect these tables to be written to first, during block statistics stage. So even if this memory contains garbage data, it should not matter.

Anyway, another important detail is that v1.5.2 is > 2 years old, and our code base has evolved since.

Would you be able to repeat the experience using the current source code in dev branch ?

i dont know how, but it does happen in my environment, and i cant repeat it in dev branch(even in my other dev environment), its strange.

A few hours ago I was able to more accurately debug that it was the zc->blockState.nextCBlock block that was the problem. If I use memset to clear this memory but all workspace, the program can also complete the compression normally.

// zstd_compress.c : 1910
zc->blockState.nextCBlock = (ZSTD_compressedBlockState_t*) ZSTD_cwksp_reserve_object(ws, sizeof(ZSTD_compressedBlockState_t));
RETURN_ERROR_IF(zc->blockState.nextCBlock == NULL, memory_allocation, "couldn't allocate nextCBlock");
//memset(zc->blockState.nextCBlock, 0, ZSTD_cwksp_align(sizeof(ZSTD_compressedBlockState_t), sizeof(void*)));

So I guess this piece of junk value might be playing some toxic role in the ZSTD_buildSequencesStatistics-> ZSTD_buildCTable->FSE_buildCTable_wksp function. But this piece of code is so complicated that I can't understand what is done.

/UPDATE/
I find the real problem now. In function FSE_buildCTable_wksp, we will calculate deltaNbBits and deltaFindState in the symbolTT array element in the last loop. But when normalizedCounter[s] == 0, The branch only calculates the value of deltaNbBits. So the deltaFindState may get a garbage value. Then when the program runs to FSE_encodeSymbol function(in fse.h), the program will get a Segmentation Fault.
statePtr->value = stateTable[ (statePtr->value >> nbBitsOut) + symbolTT.deltaFindState];

[Yann Collet]

when normalizedCounter[s] == 0,

it means the symbol s should not be present at all, not even once.
If s is nonetheless found as part of the input, then indeed there will be a pretty big problem: it's an non-codable event.

But this should not happen, because prior to calculating the tables, the process starts by histogramming the whole input. So no symbol should be missing. Only symbols which are confirmed absent will receive a weight of 0.

This is a very blatant issue, and the issue board would have witnessed mountains of segv and support requests if it was present in an earlier release such as v1.5.2.

[Felix Handte]

Is it possible that the input buffer is being modified during the compression operation? That would explain this symptom, I think. This could happen either by some other thread touching the input buffer, or if the the CCtx's internal buffers are colliding in part with the input buffer, so that Zstd is accidentally mutating the input by writing into its CCtx.

Is the code snippet you provided literally the reproduction case you've discovered? Can you describe the environment a little more? Are there other threads running in your program?