Mantis - Resin
Viewing Issue Advanced Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4698 minor always 08-03-11 11:49 08-03-11 17:17
Reporter: ferg Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: closed Product Version: 3.1.6  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 4.0.21  
Summary: 0004698: JNI threading issue with crc64/readdir
Description: (rep by Peter Mei)

In the native directory CRC code at Java_com_caucho_vfs_JniFilePathImpl_nativeCrc64, there is a call to readdir to get the directory entires. From the libc documentation and elsewhere, this function is not threadsafe, as "This [returned] structure is statically allocated and can be rewritten by a subsequent call.". It seems that the Resin use case is clearly multi-threaded, so it's possible that the returned entires change out from under us after the call is made.

The names from the readdir command are passed into crc64_generate, which looks like this:

jlong crc64_generate(jlong crc, char *value)
{
  int ch;

  if (! g_crc64_is_init)
    crc64_init();
 
  while ((ch = *value++)) {
    crc = crc64_next(crc, ch);
  }

  return crc;
}

So we look for a null terminator while CRCing the name. It seems that if the name gets overwritten while we are looking at it, and the null moves from after the position we are currently looking at (the usual case, or we would have stopped), to before (because the new name is shorter), we could potentially run off the end of this array (although this would best be explained if the underlying storage was something other than plain static memory).

We are seeing a crash at

C [libresin.so+0x89e4] crc64_generate+0x14

I didn't check yet what offset 0x14 corresponds to, but that function is small and absent inlining the *value++ is the only thing I can see that can produce a SIGSEV.
Steps To Reproduce:
Additional Information:
Relationships
Attached Files:

There are no notes attached to this issue.