Summary
A boundary-handling flaw in the flatcc schema lexer can read one byte beyond an exact-length schema buffer when the buffer ends with a digit. A specially crafted schema may trigger an application crash, causing denial of service wherever untrusted schemas are parsed.
Affected context
The issue occurs in flatcc schema parsing when all of the following conditions are present:
- The schema buffer is provided at its exact length without an additional terminating byte.
- The final byte is a decimal digit.
- The lexer processes that digit as part of an integer token.
Systems that parse schemas from untrusted files, uploads, repositories, or network-controlled sources may be exposed to the condition.
Exploit preconditions
- Attack surface: The flatcc schema lexer and any application that invokes it
- Required access: Ability to supply or influence a schema buffer
- Trigger point: Integer digit scanning near the end of an exact-length buffer
- Why exploitation is possible: The digit-scanning loop advances beyond the valid buffer boundary before checking whether more input remains
Why this happens
The underlying bug is an unchecked boundary condition in a lexer loop. When a sequence of digits reaches the final valid byte, the scanner advances its pointer and dereferences memory beyond the supplied buffer instead of stopping at the buffer boundary.
This behavior is characteristic of an out-of-bounds read and can expose adjacent memory or terminate the process when the invalid access is detected. The supplied vulnerability mapping identifies CWE-22; however, the described memory-safety behavior is more directly associated with out-of-bounds read classifications such as CWE-125.
Potential impact
- The application may crash during schema parsing.
- A service may become unavailable when repeatedly processing crafted schemas.
- Parser worker resources could be consumed by failed or repeated processing attempts.
- Diagnostic data or adjacent memory may be exposed in environments where the invalid read is observable.
General mitigation guidance
Mitigation generally focuses on making lexer boundary checks explicit and treating schema buffers as bounded data rather than implicitly terminated strings.
Common defensive patterns include:
- Checking the current pointer against the buffer end before every character read.
- Handling end-of-input while scanning numeric tokens.
- Preserving buffer length information throughout parsing.
- Rejecting malformed or incomplete schemas before deeper processing.
- Parsing schemas in isolated, least-privileged processes when inputs are untrusted.
- Reducing input trust through allowlisted sources, validation, and resource limits.
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis that flags pointer increments followed by dereferences without end-bound checks.
- Code review of lexer loops that scan digits, identifiers, or quoted values.
- Boundary-focused tests using empty, exact-length, truncated, and delimiter-free buffers.
- AddressSanitizer, UndefinedBehaviorSanitizer, and fuzzing campaigns targeting schema parsing.
- Policy enforcement requiring length-aware parsing APIs for externally supplied buffers.
- Automated review tools that identify potential off-by-one reads and missing end-of-input handling.
