fix(ws): guard _onData against a torn 2-byte frame header (OOB read + size_t underflow)

[macdylan]

Summary

When a single TCP delivery ends on exactly one byte of the next frame's 2-byte header, the STATE_FRAME_START branch of AsyncWebSocketClient::_onData():

1. reads fdata[1] out of bounds (only 1 byte is valid), and
2. computes data += 2; plen -= 2; on plen == 1, underflowing size_t to SIZE_MAX,

after which the parser walks wild memory until the device panics.

The v3.12 websocket refactor (#462) added careful torn-frame handling for the mask bytes (STATE_FRAME_MASK) and the payload, but the base 2-byte header consume is still only guarded by while (plen > 0). This PR adds the missing guard.

Reproduction

Naturally occurs under retransmission/load (a segment happens to split at a frame boundary). Deterministic trigger with a raw-socket client that writes one header byte, flushes, waits, then writes the rest:

const f = frame('t');            // any small masked text frame
sock.write(f.subarray(0, 1));    // ONE header byte in its own delivery
await sleep(60);
sock.write(f.subarray(1));       // remainder arrives in the next delivery

Evidence

Version	Result of the injection
v3.6.0	Load access fault panic at AsyncWebSocket.cpp:538, 3/3 runs under load
current main (v3.12.1)	Guru Meditation Error: Core 0 panic'ed (Store access fault) -> reboot; occasionally the accept path stalls for seconds afterwards

Tested on ESP32-C3 (arduino-esp32 3.2.1 / IDF 5.4, AsyncTCP 3.5.0); plain WS echo scenario, no TLS.

The fix

if (_pstate == STATE_FRAME_START) {
  if (plen < 2) break;  // torn base header: the delivery ends inside the 2 header bytes

  const uint8_t *fdata = data;

Dropping the un-parseable tail makes the connection desynchronize and get closed by the client - the same trade-off the adjacent plen >= 2 / plen >= 8 / plen >= 4 extended-length and mask guards already make.

A larger alternative would accumulate the base header across deliveries with a new STATE_FRAME_HEADER state, mirroring the STATE_FRAME_MASK machinery - happy to rework in that direction if you prefer it. The minimal guard is offered first because it is trivially reviewable and the desync outcome is already how the other partial-header paths behave.

Testing

• With the guard: 8/8 injection rounds clean, device stays alive, the desynced connection is closed and reaped normally.
• Without the guard: panics as above, reproducibly.

[willmmiles]

I believe #473 fixes this properly, with correct handling of frames split between multiple packets, instead of dropping the connection.

Can you please test with #473 and see if it resolves this issue in your test case?

[macdylan]

Tested websocket-parsing @ ddf5ce9 on the same bench (ESP32-C3, IDF 5.4, AsyncTCP 3.5.0) — the torn-frame suite passes cleanly, and the reassembly semantics are strictly better than the drop approach:

Injection (deterministic raw-socket tear)	Rounds	Result
base header torn after 1 byte (the historic crash trigger)	8	0 crashes
4-byte mask torn across deliveries (Safari-style)	8	0 crashes
payload torn mid-way	8	0 crashes
close frame with torn reason	8	0 crashes
random split point per frame	32	0 crashes

Connection-survival check (the differentiator vs dropping): after each torn header, a follow-up frame is answered with telemetry within 400 ms — 5/5. The parser reassembles and keeps serving on the same connection; no desync, no drop. 420 s of continuous heartbeats across the whole run, no reboots, graceful accounting for the junk fragments.

Inbound-performance note (per the earlier question in this thread): at our telemetry pull rate (10 Hz small frames) plus the 64-injection load, loop-task jitter was imperceptible in heartbeat cadence. We could not get clean numbers for high-rate inbound flood because of an unrelated baseline issue below.

One caveat that is not this PR's fault: the v3.12.x base still carries the per-request heap decline + burst wedge we reported in #482, so our device stays on the 3.6.0 tag with our 2-line guard until that lands. The parser fixes themselves are verified good from our side.

Closing this PR as superseded by #473 — thanks for the pointer and for the proper fix!