fix: stack buffer overflow in IPv6 address parsing

[EylonKrause]

Description

ncclSocketGetAddrFromString parses an [IPv6]:port (optionally [IPv6%iface]:port) string into fixed-size stack buffers, but the strncpy lengths come straight from the input with no bound (src/misc/socket.cc):

• port_str is NI_MAXSERV (32) bytes, yet strncpy(port_str, ip_port_pair + i + 2, len - i - 1) copies the entire tail after ]: — a port field longer than 31 chars overflows the stack buffer.
• if_name is 16 bytes, copied i - j - 1 (the %iface portion) with no bound.
• ip_str is NI_MAXHOST (1025) and is likewise unbounded for a pathologically long address.

These lengths derive from operator-controlled configuration (NCCL_COMM_ID, and the RAS address path), so a malformed value such as NCCL_COMM_ID = [::1]: followed by 40+ digits triggers a stack out-of-bounds write (CWE-121). The IPv4/getaddrinfo branch is unaffected.

Related Issues

None.

Changes & Impact

• src/misc/socket.cc: clamp each strncpy length to its destination buffer size (minus one for the NUL already written by the preceding memset). The (size_t) cast plus the clamp also makes any unexpected negative length safe (it becomes large, then clamps down). Valid addresses — well under the buffer sizes — are unaffected; only malformed/over-long input is now truncated instead of overflowing. Non-breaking.

Performance Impact

None — a few comparisons on the (rare) address-parse path.

Testing

• Builds clean with make src.build (no new warnings).
• AddressSanitizer repro of the parsing logic (extracted verbatim) with NCCL_COMM_ID-style input [::1]: + 40 digits:
  • Before: AddressSanitizer: stack-buffer-overflow ... WRITE of size 41 ... in strncpy (41 bytes written into the 32-byte port_str).
  • After: parses without overflow (the over-long field is truncated to the buffer).