neosys007 opened a new issue, #12955:
URL: https://github.com/apache/trafficserver/issues/12955
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:
```c
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:
```c
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
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
