ReadUint{16,32,64}Slice recurses on c[buffered:] without making progress
when the underlying Reader returns a partial Peek (buffered == 0) but no
error. An attacker-supplied wire prefix combined with a long destination
slice exhausts the goroutine stack on the destination chain.
Discovered by github.com/luxfi/warp/pulsar's FuzzPulseDeserialize
harness during the Mar-3 2026 PQ Consensus Architecture Freeze
(regression seed: testdata/fuzz/FuzzPulseDeserialize/ccdb090e0ca0007b).
Fix:
- Replace recursion with an iterative loop (O(1) stack)
- Detect zero-progress reads and return ErrZeroProgress
- Add Read{Uint16,Uint32,Uint64}SliceBounded length-prefix-aware
wrappers gated by MaxSliceLen() (default 1 MiB, configurable via
LUX_LATTICE_MAX_UINT64_SLICE_LEN env var)
- Regression tests for all three slice readers + happy path + bounded
rejection
- Update module path to github.com/luxfi/lattice/v7
- Add GPU acceleration with Metal (macOS) and CUDA backends
- Enhance threshold FHE operations
- Revert to vanilla Apache 2.0 license (remove tfhe)
- Update Go version to 1.25.5
- Merge upstream lattigo improvements
The use of OperandQP for public key is correct but a bit of an overkill, especially since public-keys
must be of size two (which requires an additional check at cast/read/write anyway) and because they
should not require to serialize ciphertext-related metadata.
The WriterTo and ReaderFrom standard interface should be sufficient for the serialization
of lattigo objects from their pointers. Other interfaces such as BinaryMarshaller should
be based on WriterTo. This is possible in an efficient way if the Writer and Reader interface
expose their internal buffer.
Vector and Matrix now use []T and [][]T as underlying types, which makes them more versatile and easy to cast to from slices.
Map still uses map[K]V as map values cannot be addressed and this is anoying to use.
I also got rid of the Codec[T] type as it can be replaced with a 3-liner (i.e., equivalent to calling the Codex and checking the error).
There is also a small change of the OperendQ.Encode method that now uses OperandQ.WriteTo instead of OperandQ.Encode (since it is a bit fasterfor some reason...). This is an experiment and more work on the serialization is needed.
zeekayandGitHub