RFR: 8049695: nsk/jdb/options/connect/connect003 fails with "Launched jdb could not attach to debuggee during 300000 milliseconds"

Chris Plummer chris.plummer at oracle.com
Wed Mar 14 23:33:07 UTC 2018


On 3/14/18 4:28 PM, Alex Menkov wrote:
> Hi Chris,
>
> On 03/14/2018 13:42, Chris Plummer wrote:
>> Hi Alex,
>>
>> I don't think prefix -> basename is what David had in mind. Those 
>> basically mean the same thing. The buffer is being used for the full 
>> name, which is why neither is really appropriate. So maybe just call 
>> it fullname, or even just name. createConnection() has a similar 
>> prefix reference that should be fixed.
>
> Ok, I don't like "fullname", "name" is already used there, so I made 
> them "objectName" (for mutex/event names) and streamName (for stream 
> name in createConnection()).
>
> updated webrev:
> http://cr.openjdk.java.net/~amenkov/shmem_long_name/webrev_open.03/
Hi Alex,

Just noticed the copyright needs updating, but otherwise looks good. No 
need for another webrev.

thanks,

Chris
>
> --alex
>
>>
>> thanks,
>>
>> Chris
>>
>> On 3/14/18 12:43 PM, Alex Menkov wrote:
>>>
>>> Updated fix:
>>> http://cr.openjdk.java.net/~amenkov/shmem_long_name/webrev_open.02/
>>>
>>> The changes:
>>> - createTransport function is fixed;
>>> - "prefix" variable is renamed to "baseName".
>>>
>>> --alex
>>>
>>> On 03/14/2018 09:45, Alex Menkov wrote:
>>>> Hi David,
>>>>
>>>>
>>>> On 03/13/2018 17:46, David Holmes wrote:
>>>>> Hi Alex,
>>>>>
>>>>> On 14/03/2018 9:14 AM, Alex Menkov wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> Please review a small fix for
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8049695
>>>>>> webrev: 
>>>>>> http://cr.openjdk.java.net/~amenkov/shmem_long_name/webrev_open/
>>>>>>
>>>>>> Root cause of the issue is jbd hungs as a result of the buffer 
>>>>>> overflow.
>>>>>>
>>>>>> In the beginning of the shmemBase.c:
>>>>>>
>>>>>> #define MAX_IPC_PREFIX 50   /* user-specified or generated name 
>>>>>> for */
>>>>>>                              /* shared memory seg and prefix for 
>>>>>> other IPC */
>>>>>> #define MAX_IPC_SUFFIX 25   /* suffix to shmem name for other IPC 
>>>>>> names */
>>>>>> #define MAX_IPC_NAME   (MAX_IPC_PREFIX + MAX_IPC_SUFFIX)
>>>>>>
>>>>>> buffer (char prefix[]) in function createStream is used to 
>>>>>> generate base name for mutex/events, so MAX_IPC_PREFIX is not big 
>>>>>> enough.
>>>>>
>>>>> Good catch! But overall this code seems to be missing bounds 
>>>>> checks everywhere. You made the "prefix" (poor name?) buffer 
>>>>> bigger (MAX_IPC_NAME) but do we know the incoming name plus the 
>>>>> appended descriptive string will fit in it?
>>>>
>>>> Yes, the possible values can be added to the shmem name (which is 
>>>> restricted by 49 chars):
>>>> ".mutex"
>>>> ".hasData"
>>>> ".hasSpace"
>>>> ".accept"
>>>> ".attach"
>>>> ".<pid>" (pid is 64bit value, max len IIRC is 19 symbols)
>>>> So extra MAX_IPC_SUFFIX (25 symbols) is enough
>>>>
>>>>> Looking at createTransport for example, it also has:
>>>>>
>>>>> char prefix[MAX_IPC_PREFIX];
>>>>>
>>>>> and it produces an error if
>>>>>
>>>>> strlen(address) >= MAX_IPC_PREFIX
>>>>>
>>>>> but otherwise copies it across:
>>>>>
>>>>> strcpy(transport->name, address);
>>>>>
>>>>> and then later does:
>>>>>
>>>>>   sprintf(prefix, "%s.mutex", transport->name);
>>>>>
>>>>> so we may have overflowed again by adding ".mutex"! The same goes 
>>>>> for the subsequent sprintf's.
>>>>
>>>> Thank you for the catch!
>>>> I looked the file for other similar issues, but somehow overlokked 
>>>> this case.
>>>> Will fix it.
>>>> Also will change confusing "prefix" name to "base_name".
>>>>
>>>> --alex
>>>>
>>>>>
>>>>> So I think there is more work to do to ensure this code is immune 
>>>>> from buffer overflows.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>> -----
>>>>>
>>>>>> --alex
>>
>>
>>




More information about the serviceability-dev mailing list