neosys007 opened a new issue, #12954:
URL: https://github.com/apache/trafficserver/issues/12954
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:
```c
if (tmp - current > MAXDNAME) {
errPtr = "Parent hostname is too long";
goto MERROR;
}
```
but then handles the optional `&hash` suffix with no analogous bound:
```c
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:
```c
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
--
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]
