S7comm server crash via oversized Read Variable count=0xFFFF (CWE-20)

[alosafuzz]

Hi, I found a remotely-triggerable crash in the S7comm server (Snap7Server/AS7Server)
via fuzz testing and wanted to report it responsibly. I didn't see a SECURITY.md or
private vulnerability reporting option on this repo, so I'm filing publicly — happy to
move to a different channel if you have one.

Summary

The snap7 S7comm server crashes when a client sends a Read Variable request
(S7 function code 0x04) with count=0xFFFF (65535 elements). The crash occurs
within ~100ms of receiving the request. The server process terminates; port 102
becomes unreachable until manually restarted. No authentication is required —
S7comm has no authentication mechanism at the transport layer.

Affected component

snap7 server library — Snap7Server / AS7Server, S7comm request handler
for S7 Read Variable (function code 0x04).

Tested on: snap7 as bundled with OpenPLC Runtime on Raspberry Pi 4 (Linux).

Trigger (description only — full PoC available privately on request)

1. Establish a normal S7comm session: TCP connect → COTP CR/CC → Setup Communication (PDU negotiation)
2. Send a Read Variable request (function code 0x04) for a DB area with count=0xFFFF
   (65535 elements), transport_size=WORD
3. Server crashes within ~100ms; TCP connection closes; port 102 becomes unreachable

Confirmed 5/5 times across independent test runs. The requested element count is never
validated against the negotiated PDU size (default 480 bytes) before the response buffer
is sized — likely an integer overflow or unchecked allocation in the buffer sizing code.

CWE: CWE-20 (Improper Input Validation)

Expected behavior (S7comm spec)

The server should return an S7 Ack_Data response with error_class=0x05 or 0x06
(access/parameter error) and remain operational, rather than crashing.

Impact

Any attacker with network access to port 102 can crash snap7 with two packets
(handshake + one malformed Read) and no credentials, since S7comm has no
authentication layer. This is a complete denial of service to all S7comm clients
(HMIs, SCADA, engineering stations) until the process is manually restarted.

Suggested fix

Validate the requested element count against the negotiated PDU size before
allocating the response buffer — if count * element_size > negotiated_pdu_size,
return an S7 error response (error_class=0x06) instead of attempting the allocation.

CVSS 3.1

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H — 7.5 HIGH

Happy to share the working PoC script privately so it isn't posted where anyone can
copy-paste a live DoS against production OT deployments. Let me know how you'd prefer
to receive it (email, private gist, etc.).

Researcher contact: Shad Malloy, shadmalloy3@gmail.com