phongn opened a new pull request, #13210:
URL: https://github.com/apache/trafficserver/pull/13210
## Problem
`ats_base64_decode()` reads out of bounds when the decodable (base64
alphabet) prefix of the input is not a multiple of four. The main loop
```c
for (size_t i = 0; i < inBytes; i += 4) {
... DECODE(inBuffer[2]) ... DECODE(inBuffer[3]) ...
}
```
iterates while `i < inBytes`, so for a prefix of length 1–3 (mod 4) it
runs one extra iteration that reads `inBuffer[2]`/`inBuffer[3]` past the
valid prefix — out of bounds of the caller's buffer when the input ends
there. The trailing adjustment then reads `inBuffer[-2]`.
AddressSanitizer confirms it; decoding a 2-character input from a
2-byte heap buffer:
```
==ERROR: AddressSanitizer: heap-buffer-overflow ... READ of size 1
0x... is located 0 bytes after 2-byte region
#0 ats_base64_decode
```
This is reachable from `TSBase64Decode()` and other callers whenever a
caller passes a buffer sized exactly to the input and the input is not
4-aligned (e.g. unpadded base64).
## Fix
Decode only complete 4-character groups in the loop, then handle a
trailing 2- or 3-character group explicitly (a lone trailing character
does not encode a full byte and is dropped, as RFC 4648 requires). No
read ever passes the alphabet prefix.
The decoded length and bytes are **unchanged for every well-defined
input** — only the out-of-bounds reads are removed. Encoding and the
lookup table are untouched.
## Testing
- Reproduced the overflow on the original code under ASan, and verified
the fix is clean on the same trigger plus a length sweep (every valid
prefix length 0–200 in exact-size buffers).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
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]
