fix lareger(>57 octets) CRL number

[miyazakh]

Description

This is an additional fix for PR9628. There is an additional vulnerability triggered by a CRL number larger than 56 octests.

In ParseCRL_Extensions(ASN_TEMPLATE code path), the CRL number Integer is parsed by calling:

    GetInt(m, buf, &localIdx, maxIdx);
  Internally, the call chain is:
    GetInt
     └─ GetASN_Items        (asn.c)
         └─ GetASN_StoreData (asn.c)
             ├─ mp_init(data->data.mp)        ← OVERWRITES m->size with
             │                                   SP_INT_DIGITS (e.g. 130)
             └─ sp_read_unsigned_bin()        ← STACK OVERFLOW HERE

For a CRL Number larger than 56 bytes, sp_read_unsigned_bin writes past the end of the 64-byte stack allocation, overflowing into adjacent stack frames.

The stack over flow can be observer with the following build configuration:

./configure --enable-crl 'CFLAGS=-DHAVE_CRL_UPDATE_CB -fsanitize=address -fno-omit-frame-pointer -g'

Then run the unit test test_wolfSSL_CTX_LoadCRL_largeCRLnum() (after modifying the CRL number to be greater than 56 octets).

Fix: Add a length pre-check before calling GetInt() to reject CRL Numbers
exceeding CRL_MAX_NUM_SZ (20 octets) in both the ASN_TEMPLATE and
non-ASN_TEMPLATE code paths of ParseCRL_Extensions.

Testing

Add new CRL certs which have >57 octets CRL number

Checklist

• added tests
• updated/added doxygen
• updated appropriate READMEs
• Updated manual and documentation

[miyazakh]

retest this please

[miyazakh]

retest this please

[miyazakh]

retest this please

[douzzer]

In one test run I saw this anomaly:

[quantum-safe-wolfssl-all-g++-latest-debug] [9 of 55] [a3b8c36cce]
    configure...   real 0m11.855s  user 0m7.757s  sys 0m5.159s
    build...   real 0m10.114s  user 1m50.869s  sys 0m7.683s
    check...FAIL: scripts/crl-gen-openssl.test
   real 0m25.253s  user 0m13.917s  sys 0m5.795s

scripts/crl-gen-openssl.log tail:
Checking RSA CRL: certs/crl/crlRsaOut.pem
expected successful verification for RSA CRL with  certs/client-ca-cert.pem
FAIL scripts/crl-gen-openssl.test (exit status: 1)

check exited with status 2
    scenario started 2026-03-06T04:38:28.290456Z, real elapsed 0m47.403860s
    quantum-safe-wolfssl-all-g++-latest-debug fail_check
    failed config: 'EXTRA_CPPFLAGS=-Werror' '--srcdir' '.' '--disable-jobserver' '--enable-option-checking=fatal' '--enable-all' '--enable-acert' '--enable-dtls13' '--enable-dtls-mtu' '--enable-dtls-frag-ch' '--enable-dtlscid' '--enable-quic' '--with-sys-crypto-policy' '--enable-debug' '--enable-debug-trace-errcodes' '--enable-sp-math-all' '--enable-experimental' '--enable-kyber=yes,original' '--enable-lms' '--enable-xmss' '--enable-dilithium' '--enable-dual-alg-certs' '--disable-qt' 'CC=g++-16' 'CFLAGS=-DTEST_ALWAYS_RUN_TO_END' 'CPPFLAGS=-DNO_WOLFSSL_CIPHER_SUITE_TEST -DWOLFSSL_OLD_PRIME_CHECK'
    EXE: 'run_untrusted_task' 'make' 'EXTRA_CFLAGS=-fdiagnostics-color=always -fmax-errors=20' '--quiet' 'WOLFSSL_OPENSSL_TEST=1' '-j' '36' 'check'

A second run didn't repeat the error. I think there might be a stochastic bug here and I want to test more thoroughly.

[miyazakh]

Sure. I didn't see the error on my side. Used g++-14 instead of g++-16.

./configure EXTRA_CPPFLAGS=-Werror --srcdir . --disable-jobserver --enable-option-checking=fatal --enable-all --enable-acert --enable-dtls13 --enable-dtls-mtu --enable-dtls-frag-ch --enable-dtlscid --enable-quic --with-sys-crypto-policy --enable-debug --enable-debug-trace-errcodes --enable-sp-math-all --enable-experimental --enable-kyber=yes,original --enable-lms --enable-xmss --enable-dilithium --enable-dual-alg-certs --disable-qt CC=g++-14 CFLAGS=-DTEST_ALWAYS_RUN_TO_END 'CPPFLAGS=-DNO_WOLFSSL_CIPHER_SUITE_TEST -DWOLFSSL_OLD_PRIME_CHECK'

[miyazakh]

retest this please

[douzzer]

Saw the glitch on scripts/crl-gen-openssl.test in a run without this PR, so this one wasn't to blame for it.

[miyazakh]

retest this please