fix: guard SDS buffer free-space calculation against invalid count state

[orbisai0security]

Summary

This change hardens sdsBufferWrite() by ensuring cnt_free is clamped to 0 when cnt_used is greater than or equal to the configured buffer size.

Under normal operation, num is already limited to the available free space before the memcpy calls. This patch is therefore intended as defensive robustness against an invalid/corrupted counter state, not as a confirmed, directly reachable heap overflow.

Changes

• sds/sds_buffer.c

Verification

• Build passes
• Scanner re-scan confirms fix
• LLM code review passed

---

Automated security fix by OrbisAI Security

[MiloradCvjetkovic]

memcpy cannot be called with num exceeding the space available in the ring buffer because in code following mentioned line

SDS-Framework/sds/sds_buffer.c

Lines 181 to 186 in 7bc88c3

	if (buf_size < cnt_free) {
	num = buf_size;
	} else {
	// not enough space in buffer
	num = cnt_free;
	}

the variable num is limited to either requested buf_size or number of available bytes cnt_free so that statement does not hold.

[orbisai0security]

Thanks for reviewing. I agree with your point that under the normal ring-buffer invariant, num is clamped to cnt_free before the memcpy, so the original description overstated the direct exploitability.

The intended change is narrower: it hardens the free-space calculation against a broken/corrupted invariant where cnt_used >= buf_size. In that case, the current unsigned subtraction can underflow and produce a large cnt_free, whereas the proposed expression clamps free space to 0.

I’m happy to reframe this PR as defensive robustness rather than a critical vulnerability, for example:

fix: guard SDS buffer free-space calculation against invalid count state

And update the description to remove the “critical”/heap-overflow wording unless there is a reachable path that violates the ring-buffer invariant.