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

[neosys007]

Hello Apache Traffic Server maintainers,

I would like to report what appears to be a real current-head overflow in the primary-parent configuration parsing path. I rechecked current upstream head on 2026-03-10 before writing this report.

I want to be careful about scope: this is a local configuration parsing bug, not a remotely triggerable HTTP request bug.

The current code explicitly checks the hostname length:

if (tmp - current > MAXDNAME) {
    errPtr = "Parent hostname is too long";
    goto MERROR;
}

but then handles the optional &hash suffix with no analogous bound:

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

The destination field is:

char hash_string[MAXDNAME + 1];

inside struct pRecord.

So current head already proves the intended maximum for the hostname field, but not for the hash suffix. If an administrator provides a parent entry with a very long &hash_string, the primary-parent branch copies strlen(tmp3) bytes starting at tmp3 + 1 into a fixed hash_string[MAXDNAME + 1] with no length check.

Why I do not think this is a false positive:

• the hostname check does not cover the hash_string branch
• pRecord objects are allocated in arrays, so overflowing the last field corrupts subsequent records
• the path is real config parsing in ParentSelection, not a synthetic test
• the bug is visible directly in current-head code semantics

I am not claiming remote exploitability. The precise claim is: a crafted parent.config / parent-rule entry with an overlong &hash suffix overflows the primary hash_string field during configuration parsing.

The obvious fix is to apply a MAXDNAME bound to the hash_string suffix before the memcpy().

Best regards,
Pengpeng Hou

[bryancall]

Thank you for the careful report. This is fixed on master. PR #12985 ("Check valid parent selection hash string"), merged on 2026-03-25, adds the exact MAXDNAME bound you suggested. In ProcessParents the code now rejects an overlong hash suffix before the copy:

if (tmp3 && strlen(tmp3 + 1) > MAXDNAME) {
    errPtr = "Parent hash string is too long";
    goto MERROR;
}

That guard runs ahead of both the primary and secondary parent branches, so both memcpy() paths into the fixed hash_string[MAXDNAME + 1] buffer are now bounded, and the pull request also added a regression test covering the overlong and max-length cases. The fix is targeted at the 10.2.0 release milestone (not yet released). Closing as resolved.