RFR: 8353727: HeapDumpPath doesn't expand %p [v2]
Kevin Walls
kevinw at openjdk.org
Tue Apr 8 13:50:19 UTC 2025
On Tue, 8 Apr 2025 13:13:25 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:
>> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
>>
>> - length checking update
>> - Chris feedback
>
> src/hotspot/share/services/heapDumper.cpp line 2779:
>
>> 2777: }
>> 2778: // Then add the default name, with %p substitution. Use my_path temporarily.
>> 2779: if (!Arguments::copy_expand_pid(dump_file_name, strlen(dump_file_name), my_path, JVM_MAXPATHLEN - max_digit_chars)) {
>
> IIUC there is a pre-existing bug, and if I am right one you should fix: this calculation assumes that there is only a single %p. There may be multiple. Many. E.g. as a malicious attempt to cause a buffer overflow.
>
> This is what I meant with stringStream. stringStream offers protection against stuff like that without the manual buffer counting headaches. I would give Arguments a method like this:
>
> print_expand_pid(outputStream* sink, const char* input);
>
>
> and in there print to sink, with print or putc. This would never truncate. Then use it like this:
>
>
> outputStream st(caller buffer, caller buffer size)
> if (have HeapDumpPath) {
> Arguments::print_expand_pid(st, HeapDumpPath);
> if (st->was_truncated()) return with warning
> // now st->base() ist der expanded heap path. Test if its a directory etc
> }
> // append file name
> Arguments::print_expand_pid(st, dump_file_name);
> if (st->was_truncated()) return with warning
>
>
> Just a rough sketch. And fine for followup PRs, though I think it may make your life easier if you do it now.
Thankfully copy_expand_pid does handle multiple %p replacements. It seems good to use that to check the buffer length, partly for that reason, as just knowing a max number of digits wasn't so flexible if many %p were present.
Thanks for the other ideas!
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24482#discussion_r2033234374
More information about the serviceability-dev
mailing list