Summary
src/multiplayer/basic.h trusts vector sizes read from a multiplayer DataBuffer and calls std::vector::resize() before applying any upper bound.
Affected paths on current master:
- generic
sp::io::operator>>(DataBuffer&, std::vector<T>&) around line 10 (uint32_t size);
BASIC_REPLICATION_VECTOR receive path around line 86 (size_t size).
A malformed or hostile session peer can advertise a very large size with a small packet. The receiver attempts the allocation before reading the vector elements or sparse updates, which can cause memory exhaustion, std::bad_alloc, or process termination. The later index check in BASIC_REPLICATION_VECTOR protects element access but runs only after the resize.
Scope
This is a denial-of-service risk, not a demonstrated code-execution issue. The realistic boundary is a peer able to send multiplayer traffic to a game session; I am not assuming the service is publicly exposed.
The same code is currently present in downstream fork VaroTv7/espaciokooplagunak and is tracked there as EspacioKoop/espaciokooplagunak#271.
Suggested direction
Reject advertised vector sizes above an explicit protocol limit before resizing, for both paths. The incremental vectors currently using BASIC_REPLICATION_VECTOR are beam mounts, shield entries and missile-tube mounts, so a conservative protocol maximum can still be far above legitimate ship data.
It would also be useful to add a focused deserialization regression that feeds an oversized declared count and verifies that no resize/allocation is attempted. I have intentionally not included a network exploit payload.
Summary
src/multiplayer/basic.htrusts vector sizes read from a multiplayerDataBufferand callsstd::vector::resize()before applying any upper bound.Affected paths on current
master:sp::io::operator>>(DataBuffer&, std::vector<T>&)around line 10 (uint32_t size);BASIC_REPLICATION_VECTORreceive path around line 86 (size_t size).A malformed or hostile session peer can advertise a very large size with a small packet. The receiver attempts the allocation before reading the vector elements or sparse updates, which can cause memory exhaustion,
std::bad_alloc, or process termination. The later index check inBASIC_REPLICATION_VECTORprotects element access but runs only after the resize.Scope
This is a denial-of-service risk, not a demonstrated code-execution issue. The realistic boundary is a peer able to send multiplayer traffic to a game session; I am not assuming the service is publicly exposed.
The same code is currently present in downstream fork
VaroTv7/espaciokooplagunakand is tracked there as EspacioKoop/espaciokooplagunak#271.Suggested direction
Reject advertised vector sizes above an explicit protocol limit before resizing, for both paths. The incremental vectors currently using
BASIC_REPLICATION_VECTORare beam mounts, shield entries and missile-tube mounts, so a conservative protocol maximum can still be far above legitimate ship data.It would also be useful to add a focused deserialization regression that feeds an oversized declared count and verifies that no resize/allocation is attempted. I have intentionally not included a network exploit payload.