fuzz-tests: improve fuzz-bech32
#8311
Conversation
Changelog-None: Use the common library utilities for temporary allocations instead of manually calling `malloc` and `free`. This makes the code conformant with rest of the codebase and reduces the chances of leaks.
According to `common/bech32.h`, the valid values of witness program version are between 0 and 16 (inclusive). Update the test to iterate over all of these values.
tests/fuzz/fuzz-bech32.c
Outdated
| uint8_t *converted = tal_arr(tmpctx, uint8_t, size * 2); | ||
| size_t converted_len = 0; | ||
| if (bech32_convert_bits(converted, &converted_len, 5, data, size, 8, 1)) { | ||
| uint8_t *deconverted = tal_arr(tmpctx, uint8_t, converted_len * 2); |
There was a problem hiding this comment.
Does deconverted need to be size converted_len * 2? If we're going from 5 bits back to 8 bits, shouldn't we need at most size bytes?
tests/fuzz/fuzz-bech32.c
Outdated
| @@ -60,5 +60,18 @@ void run(const uint8_t *data, size_t size) | |||
| assert(memcmp(data_out, data, data_out_len) == 0); | |||
| } | |||
|
|
|||
| /* Test 8-to-5 bit roundtrip conversion */ | |||
There was a problem hiding this comment.
Would it make sense to do the roundtrip as part of the above call to bech32_convert_bits?
There was a problem hiding this comment.
Makes sense, the calls above don't test a whole lot.
Currently, the test only verifies the 5-to-8 bit conversion. Replace it with a roundtrip check that verifies 8-to-5 bit conversion as well.
Change in the fuzzing scheme of fuzz-bech32 led to the discovery of test inputs that result in greater in code coverage. Add these inputs to the test's seed corpus.
| data_out_len = 0; | ||
| bech32_convert_bits(data_out, &data_out_len, 8, data, size, 5, 0); | ||
| /* First conversion uses pad=1 to ensure all bits are captured. */ | ||
| if (bech32_convert_bits(data_out, &data_out_len, 5, data, size, 8, 1)) { |
There was a problem hiding this comment.
IIUC the original code converts 5 bits to 8 bits, while now this converts 8 bits to 5 bits. This change largely invalidates the existing corpus.
Can we keep the same direction of the conversion, to maximize the corpus effectiveness?
There was a problem hiding this comment.
The test does perform a 8 to 5 bit conversion later in the code to perform the roundtrip check:
if (bech32_convert_bits(deconv_data_out, &deconv_data_out_len, 8,
data_out, data_out_len, 5, 0))
Do you suggest that we should swap the order of the conversions-that is, 5 to 8 first then 8 to 5?
There was a problem hiding this comment.
Original Code
bech32_convert_bits(data_out, &data_out_len, 8, data, size, 5, 1);New Code
if (bech32_convert_bits(data_out, &data_out_len, 5, data, size, 8, 1)) {
...
bech32_convert_bits(deconv_data_out, &deconv_data_out_len, 8, data_out, data_out_len, 5, 0);
}Corpus Invalidation
Since the original corpus was created with the original code, it optimizes coverage for the 5-to-8 bit conversion. The new code reverses the direction of the initial conversion, which means all those original corpus inputs are no longer optimized for this fuzz target.
Yes there is still a 5-to-8 bit conversion later on for the round trip, but that doesn't solve the corpus invalidation since the second conversion is done on data_out, not data.
Add improvements to
tests/fuzz/fuzz-bech32and add the coverage increasing inputs to the corresponding corpus.Checklist
Before submitting the PR, ensure the following tasks are completed. If an item is not applicable to your PR, please mark it as checked:
CC: @morehouse