dxbjavid opened a new pull request, #13404: URL: https://github.com/apache/trafficserver/pull/13404
escapify_url_common takes a counted string, (url, len_in), and every caller that hands it a destination buffer relies on that. In the common case where nothing in the input needs escaping it took a shortcut and used ink_strlcpy to copy the source over, which walks the source looking for a NUL rather than stopping at len_in. A lot of the callers have no terminator to find: TSStringPercentEncode is handed pointers straight into the MIME header heap by plugins like cachekey and slice, and Crypto::Escape::Encode in cripts passes a string_view, so an ordinary header or URL value with no escapable byte reads off the end and can drop unrelated adjacent bytes into the destination while len_out still claims len_in. I noticed it while looking at how the cripts helper sizes its output and then reran the existing test with an exactly-sized heap allocation under ASan, which reports a heap-buffer-overflow at the ink_strlcpy line. Copying len_in bytes and terminating explicitly keeps the fast pa th honest about its own contract, and I tightened the entry guard to require room for that terminator since dst_size == len_in previously passed and left nowhere to put it. Added the unterminated case to test_Encoding.cc so it stays covered. -- 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]
