Replace VLA with heap allocation in RDB entity decoders
fix(serializer): replace VLA with heap allocation in RDB entity decoders (#1973)
Replace VLA with heap allocation in RDB entity decoders7d1543-fix-replace-vla-with-heap-allocation-in-cve-2026-7827fixreplace vla heap allocation rdb entity
Committed by gkorland
commit message
fix(serializer): replace VLA with heap allocation in RDB entity decoders (#1973)
* fix(serializer): replace VLA with heap allocation in RDB entity decoders
Replace variable-length array (VLA) stack allocations in _RdbLoadEntity
with bounded heap allocations (rm_malloc/rm_free) across all decoder
versions (v10-v19).
The property count read from the RDB stream was used directly to size
C99 VLAs on the stack. With a large property count value, this could
exceed the thread stack size and crash the process.
Changes applied to all 10 decoder files:
- Replace SIValue vals[n] and AttributeID ids[n] VLAs with rm_malloc
- Add rm_free calls after AttributeSet_Add
- Add ASSERT(n <= 65536) upper bound check
- Add early return for n==0 in v10-v13 decoders (already present in v14+)
- Fix loop variable type from int to uint64_t in older decoders
Co-authored-by: Copilot <[email protected]>
* fix(serializer): tighten property count bound to UINT16_MAX
The encoder writes attr_count as uint16_t (from AttributeSet_Count),
so the maximum possible value in a well-formed RDB is 65535 (UINT16_MAX),
not 65536. Update ASSERT to reflect this precise invariant.
Co-authored-by: Copilot <[email protected]>
* stack back array for small attribute sets
---------
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Roi Lipman <[email protected]>
Co-authored-by: Roi Lipman <[email protected]>Editor assessment
This commit patches CVE-2026-7827. Exemplary. The subject states the mechanism and the area, and the body explains the VLA stack exhaustion, the bounded heap replacement across all ten decoders, the UINT16_MAX invariant derived from the encoder, the early return for empty sets, and the small-set stack array. It is precise, complete and teaches a reader why the bound is exactly 65535. Scope and type are perfect. Style-wise the header, scope and body are all correct and well separated; the message is complete as written.