ext/snmp: hardening: replace unbounded strcat with offset-tracked snprintf

[somethingwithproof]

The suffix-as-keys code path in php_snmp builds a dotted OID suffix
string by appending with strcat into a fixed 2048-byte buf2 array.
The overflow is not reachable in practice: net-snmp's BER decoder
enforces MAX_OID_LEN=128, and the worst-case suffix (128 subidentifiers
at 11 bytes each) produces 1408 bytes, within the buffer.

Replace the strcat loop with direct snprintf into buf2 at a tracked
offset, breaking out of the loop if the buffer would be exhausted.
Defense-in-depth against future net-snmp parser regressions.

[somethingwithproof]

Closing to re-evaluate the appropriate disclosure channel.

[somethingwithproof]

Reopening as a defense-in-depth hardening fix.

After further analysis, the underlying condition (OID name_length > 128 subidentifiers) is prevented by net-snmp's BER decoder: asn_parse_objid() enforces MAX_OID_LEN and returns NULL if the wire-format OID exceeds the output buffer, causing snmp_pdu_parse() to abort the entire PDU. With MAX_OID_LEN=128 and max 10-digit subidentifiers, the worst-case suffix string is 128 * 11 = 1408 bytes, within the 2048-byte buffer.

However, net-snmp has had historical CVEs in its OID parser (e.g., CVE-2019-20892), so this bounds-checked approach provides a safety net against future parser regressions. The fix replaces the unbounded strcat loop with snprintf at a tracked offset, which is also cleaner code regardless of the overflow risk.

[ndossche]

FWIW, I agree this does not fix an actual issue but is a hardening patch.
I remember looking at this a while ago too and concluding the overflow is actually impossible.
I think the commit/PR title should be updated to reflect that.

[somethingwithproof]

Updated commit subject and PR title to reflect hardening.

[devnexen]

nit: I would rather see it as size_t type.

[somethingwithproof]

Fixed, squashed into the single commit.

[devnexen]

This defensive programming change looks good to me.