[BUG] secondary parent `hash_string` copy lacks the `MAXDNAME` bound already used for `hostname`

[neosys007]

I would like to report what appears to be the same current-head overflow pattern in the secondary-parent branch of ParentSelection.cc. I rechecked current upstream head on 2026-03-10 before writing this report.

As in the primary-parent case, current head checks the hostname length but not the &hash suffix length. The secondary branch is:

memcpy(this->secondary_parents[i].hostname, current, tmp - current);
...
if (tmp3) {
    memcpy(this->secondary_parents[i].hash_string, tmp3 + 1, strlen(tmp3));
    this->secondary_parents[i].name = this->secondary_parents[i].hash_string;
}

and the destination is again:

char hash_string[MAXDNAME + 1];

inside struct pRecord.

I am intentionally making the same narrow claim as for the primary branch:

• local configuration parsing bug
• not a remote HTTP issue
• overflow condition depends on an overlong &hash_string suffix in parent configuration input

Why I think it is still a real bug:

• the only explicit MAXDNAME check in this parsing block applies to hostname
• the secondary hash_string copy has no corresponding bound
• pRecord instances are stored in arrays, so the overflow does not stop at a harmless tail buffer

This branch should receive the same fix as the primary-parent branch: reject overlong hash suffixes before the copy.

Best regards,
Pengpeng Hou
ISCAS