stratum: fix two pool-controlled crash vectors (notify type confusion, negative extranonce2_size)

[Schnitzel]

Reported via coordinated disclosure by the 256 Foundation Red Team (findings RT-2026-050 / RT-2026-051). Two independent pool-controlled crash vectors in the stratum v1 parser, each reboot-looping the miner. Both are availability-only (DoS); no code execution observed. Maintainer team asked for a public PR.

Issue 1 — mining.notify type confusion (crash → reboot loop)

parse_mining_notify() in components/stratum/stratum_api.c dereferenced ->valuestring on cJSON items without verifying they are strings. A mining.notify with non-string/null prevhash, coinbase1/2, merkle entries, version, nbits, or ntime reached strdup(NULL) / strtoul(NULL) / hex2bin(NULL) and crashed the stratum task → panic → reboot → reconnect → re-crash: a permanent reboot loop.

Trigger example:

{"id":null,"method":"mining.notify","params":["aa",12345,"00","00",[],"20000000","1a02b290","66000000",true]}

Reproduced on v2.14.2 hardware (panic loop, 9–16 s uptime cycles, 8 cycles observed) and on a host build of master @ dec2b46 (ASan: wrap_strdup → STRATUM_V1_parse). Since stratum v1 is plaintext by default, the trigger is reachable by the pool operator or any LAN MITM.

Fix (commit 1): validate cJSON_IsString for params[1..3], each merkle branch entry, and params[5..7] before use; reject the message (connection survives) like the existing job_id/param-count/merkle-count checks.

Issue 2 — negative extranonce2_size accepted (crash on next job)

parse_set_extranonce() / parse_subscribe_result() validated EN2 size only on the high side (>32 clamp). A negative size (e.g. −1) was stored as signed int, then passed to extranonce_2_generate() whose length parameter is uint32_t: −1 wraps to 4294967295 and the function memset()s a VLA of that size on the task stack → crash when the next job is generated.

Master-only regression: v2.14.2 parses the size as unsigned (−1 → 4294967295) and the existing >32 clamp fires (verified on hardware); the signed acceptance path exists on master @ dec2b46.

Fix (commit 2): reject extranonce_2_len < 1 in parse_set_extranonce and parse_subscribe_result, reject it in the task handler, and guard the generate_work() call site (defense in depth at the VLA).

Verification

Host fuzz harness (ESP-IDF linux target, ASan+UBSan, production stratum_v1_task + components/stratum built unmodified except these patches):

• Before: 7 distinct crash sites from notify type confusion; EN2 −1 accepted.
• After: zero crashes across the full 23-case battery (120 s loop); all 19 isolated prober cases survive; the 7 former crash sites are clean rejects (Invalid prev_block_hash/coinbase in mining.notify); EN2 −1/0 rejected.
• No regressions: EN2 255/1 000 000 still clamp to 32; valid subscribe (EN2 4), valid notify parse, difficulty flows unchanged; 1 MB line tolerated; client.reconnect still not followed to advertised addresses.

See also

#1881 — the difficulty-validation fix (parse_set_difficulty range check, our ref RT-2026-052), split out per maintainer preference.

[Schnitzel]

Fix verified on real hardware (2026-08-15). Flashed a build of master + these two commits (v2.14.0-50-ga18520a-dirty) via OTA onto a Bitaxe (board 401 / BM1368) that previously panic-looped on v2.14.2, pointed it at a hostile pool, and re-sent the original payloads:

• mining.notify with numeric prevhash (the pre-fix crash trigger): now rejected — device log shows Invalid prev_block_hash/coinbase in mining.notify, mining continues uninterrupted.
• set_extranonce with size −1: now rejected — Invalid extranonce_2_len -1 in set_extranonce; the unit then mined 14+ hours on the hostile pool with zero resets (~23.6k shares).

(Unit reverted to stock v2.14.2 after the test.)