RFR (XS): 8175510 Null pointer dereference in getModuleObject of JPLISAgent.c:790

David Holmes david.holmes at oracle.com
Fri Oct 13 01:01:12 UTC 2017


Hi Serguei,

Seems quite reasonable.

Reviewed.

Thanks,
David

On 13/10/2017 8:21 AM, serguei.spitsyn at oracle.com wrote:
> Please, review a fix for the Parfait bug:
> https://bugs.openjdk.java.net/browse/JDK-8175510
> 
> Webrev:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8175510-jplis-parfait.1/
> 
> 
> Summary:
> 
>    This is the main fragment from the Parfait report:
> 
> 
>         getModuleObject
> 
> FileExpandCollapseLine 
> #jdk/src/java.instrument/share/native/libinstrument/JPLISAgent.c
> jdk-9+180-JDK9_linux
> 
> 783. 	
> 
>      int len = (last_slash == NULL) ? 0 : (int)(last_slash - cname);
> 
> 784. 	
> 
>      char* pkg_name_buf = (char*)malloc(len + 1);
> 
> 785. 	
> 786. 	
> 
>      jplis_assert_msg(pkg_name_buf != NULL, "OOM error in native tmp buffer allocation");
> 
> Pointer checked against constant 'NULL' but does not protect the 
> dereference.
> 787. 	
> 
>      if (last_slash != NULL) {
> 
> 788. 	
> 
>          strncpy(pkg_name_buf, cname, len);
> 
> 789. 	
> 
>      }
> 
> 790. 	
> 
>      pkg_name_buf[len] = '\0';
> 
> *Null pointer dereference not protected by null check*
> Write to pointer pkg_name_buf that could be constant 'NULL'
> 
> 
>    The malloc can return NULL in a case of OOME.
>    The assert at L786 checks the returned pointer for NULL but does not 
> protect the dereference at L790.
>    The fix is to replace the assert with printing a error message and 
> returning with NULL from the getModuleObject().
>    It must be safe as the returned result is passed to the 
> sun.instrument.InstrumentationImpl.transform()
>    which handles null passed as in the module parameter.
> 
> Thanks,
> Serguei
> 


More information about the serviceability-dev mailing list