CVE-2026-71254

This is a buffer overflow in nanoMODBUS's compound Modbus function handler (function code 0x14) where a uint8_t accumulator used to track cumulative response size overflows when processing the maximum valid 35 sub-requests at maximum individual size. The handler validates that each record_length doesn't exceed 124 bytes and that the total request fits within 245 bytes — these checks look correct in isolation but never validate the compound case. The overflow causes an out-of-bounds write of up to 8KB into the response buffer allocated by the calling function, corrupting adjacent heap memory. What makes this actionable is the validation gap: the developer checked individual sub-requests but not their sum. When extending a handler from a smaller operational range to the full specification limit (35 sub-requests), the uint8_t accumulator silently overflows because 35 × 124 = 4340, far exceeding the 255 capacity of a uint8_t. Anyone reviewing this code should verify that compound operation handlers validate cumulative output size before allocation, not just individual parameter bounds. The fix requires a larger accumulator type (uint16_t minimum) plus an explicit check that total_response_size <= available_buffer_space. The context shifts this from a theoretical bug to a credible exploitation scenario. Embedded deployments of this library typically lack memory protection mechanisms, and the deterministic 8KB overflow can corrupt adjacent ICS control structures. On bare-metal controllers running Modbus/TCP to field devices, this memory layout predictability means reliable exploitation is achievable — the out-of-bounds write targets known offsets in the heap, not random memory. This is not "denial of service only"; it creates conditions for process logic corruption on controllers where remote patching is operationally difficult. Treat this as a high-severity finding in ICS environments, not a low-impact buffer overflow. When auditing similar Modbus implementations, look for compound operations (function codes that accept multiple sub-requests) and verify they pre-calculate total response size using an accumulator type sized to the maximum possible sum, not the maximum single element.

Reviewed through automated stages and approved by a human before publication.