RFR (S): 8129786: Buffer overrun when passing long not existing option in JDK 9
Dmitry Dmitriev
dmitry.dmitriev at oracle.com
Wed Jul 1 16:49:50 UTC 2015
On 01.07.2015 19:42, Daniel D. Daugherty wrote:
>
> On 7/1/15 10:38 AM, Dmitry Dmitriev wrote:
>> Hello Dan,
>>
>> Thank you for review! Updated webrev:
>> http://cr.openjdk.java.net/~ddmitriev/8129786/webrev.01/
>> <http://cr.openjdk.java.net/%7Eddmitriev/8129786/webrev.01/>
>> Please see my comments inline.
>>
>> Regards,
>> Dmitry
>>
>> On 01.07.2015 16:49, Daniel D. Daugherty wrote:
>>> > Webrev: http://cr.openjdk.java.net/~ddmitriev/8129786/webrev.00/
>>>
>>> src/share/vm/runtime/arguments.cpp
>>> L840: if (arg_len <= BUFLEN) {
>>> Please add a comment. Perhaps:
>>>
>>> // Only make the obsolete check for valid arguments.
>> Done!
>>>
>>> L843: strncpy(stripped_argname, argname, arg_len);
>>> L844: stripped_argname[arg_len] = '\0'; //strncpy doesn't
>>> null terminate.
>>> This is not due to your change but this comment isn't quite
>>> right.
>>> Perhaps:
>>>
>>> stripped_argname[arg_len] = '\0'; // strncpy may not
>>> null terminate.
>>>
>>> strncpy() null terminates if the length of 'argname' is
>>> less than arg_len. Also added one more space after ';'
>>> and added a space after '//'.
>> Done!
>>>
>>> L847: char version[256];
>>> Can you change this '256' to BUFLEN+1 also?
>> I prefer to leave it as is, because there are no relationship between
>> 'version' and BUFLEN. BUFLEN is used for parsing options, thus I use
>> it for stripped_argname. But I think it will be better not to use it
>> for 'version'.
>
> Is there some constant hanging around that is appropriate?
> A literal '256' is just bugging me... :-)
Yes, I agree with you :) But I don't see any of them around.
>
>
>>
>>>
>>> test/runtime/CommandLine/TestLongUnrecognizedVMOption.java
>>> L27: * @summary Verify that JVM correctly process very long
>>> unregnized VM option
>>> Typo: 'process' -> 'processes'
>>> Typo: 'unregnized' -> 'unrecognized'
>>>
>> Done!
>>> L29: * @modules java.management
>>> Why this module?
>> I got this dependency from script which used to find dependencies of
>> test code.
>
> OK, but why? I see nothing in this test that requires the
> java.management module...
I think that because jdk.test.lib.ProcessTools is depends on
java.management and this leads to the test dependency.
Thank you,
Dmitry
>
> Dan
>
>
>>>
>>> L49: extra blank line at the end; jcheck may not like this
>>>
>> Done!
>>> Thumbs up. I don't need to see another webrev if you
>>> decide to fix these minor nits.
>>>
>>> Dan
>>>
>>>
>>> On 7/1/15 6:49 AM, Dmitry Dmitriev wrote:
>>>> Hello,
>>>>
>>>> Please review this small fix and new test. Also, I need a sponsor
>>>> for this fix, who can push it.
>>>>
>>>> In this fix logic for stripped_argname was put into "if (arg_len <=
>>>> BUFLEN)" statement. stripped_argname is used only to check is
>>>> option is newly obsolete. Since valid VM option should be not
>>>> bigger than 255 characters(BUFLEN value), then obsolete_jvm_flags
>>>> contains only options with strlen <= BUFLEN.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~ddmitriev/8129786/webrev.00/
>>>> <http://cr.openjdk.java.net/%7Eddmitriev/8129786/webrev.00/>
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8129786
>>>> Tested: JPRT(with new test), hotspot all & vm.quick
>>>>
>>>> Thanks,
>>>> Dmitry
>>
>
More information about the hotspot-runtime-dev
mailing list