LLM disclosure: This issue report was prepared by an LLM assistant (OpenAI ChatGPT) for the GitHub submitter. Follow-up discussion is available through the submitter.
On current master (a71ae8281742ac638bc75baa4334f2292251e0eb), the scrypt CLI accepts NaN for the floating-point -m memory-fraction option and later aborts on an internal assertion instead of rejecting the option cleanly.
Minimal reproduction:
printf x > /tmp/scrypt-nan-input
SCRYPT_TEST_PASS=abc ./scrypt enc -m NaN \
--passphrase env:SCRYPT_TEST_PASS \
/tmp/scrypt-nan-input /tmp/scrypt-nan-output
Observed result:
scrypt: lib-platform/util/memlimit.c:271: memtouse: Assertion `(maxmemfrac > 0) && (maxmemfrac <= 1.0)' failed.
Aborted (core dumped)
The process exits with signal-derived status 134 in the test environment. Lower-case nan behaves the same way.
Expected result:
NaN should be rejected as an invalid -m value with an ordinary error exit, just like other values outside the accepted range.
Root cause:
libcperciva/util/parsenum.h::parsenum_float() parses the input using strtod() and then range-checks it using (val < min) || (val > max). For IEEE NaN, both comparisons are false, so the parser accepts NaN as if it were in range. The value later reaches memtouse(), whose maxmemfrac > 0 && maxmemfrac <= 1.0 precondition fails and triggers the assertion.
I also verified locally that explicitly rejecting isnan(val) in parsenum_float() makes this input return a normal option error, and a focused regression plus the full make test SMALLMEM=1 suite passed under ASan/UBSan. I have not submitted a patch because the repository's bounty rules state that bug bounties are paid for reports rather than patches.
LLM disclosure: This issue report was prepared by an LLM assistant (OpenAI ChatGPT) for the GitHub submitter. Follow-up discussion is available through the submitter.
On current master (
a71ae8281742ac638bc75baa4334f2292251e0eb), thescryptCLI acceptsNaNfor the floating-point-mmemory-fraction option and later aborts on an internal assertion instead of rejecting the option cleanly.Minimal reproduction:
Observed result:
The process exits with signal-derived status 134 in the test environment. Lower-case
nanbehaves the same way.Expected result:
NaNshould be rejected as an invalid-mvalue with an ordinary error exit, just like other values outside the accepted range.Root cause:
libcperciva/util/parsenum.h::parsenum_float()parses the input usingstrtod()and then range-checks it using(val < min) || (val > max). For IEEE NaN, both comparisons are false, so the parser accepts NaN as if it were in range. The value later reachesmemtouse(), whosemaxmemfrac > 0 && maxmemfrac <= 1.0precondition fails and triggers the assertion.I also verified locally that explicitly rejecting
isnan(val)inparsenum_float()makes this input return a normal option error, and a focused regression plus the fullmake test SMALLMEM=1suite passed under ASan/UBSan. I have not submitted a patch because the repository's bounty rules state that bug bounties are paid for reports rather than patches.