I found a possible JNI string leak and an unchecked-null dereference in the Windows implementation of openPort().
File: src/main/cpp/windows/jssc.cpp
Function: Java_jssc_SerialNativeInterface_openPort
Relevant code:
const char* port = env->GetStringUTFChars(portName, JNI_FALSE);
//since 2.1.0 -> string concat fix
char portFullName[MAX_PORT_NAME_STR_LEN];
if(strlen(prefix) + strlen(port) + 1 > sizeof(portFullName)){
return (jlong)((HANDLE)jssc_SerialNativeInterface_ERR_PORT_NOT_FOUND);
}
strcpy_s(portFullName, prefix);
strcat_s(portFullName, port);
//<- since 2.1.0
HANDLE hComm = CreateFile(portFullName, ...);
env->ReleaseStringUTFChars(portName, port);GetStringUTFChars() returns a native string that must be paired with
ReleaseStringUTFChars(). The only release is after CreateFile(), but the
length-check path returns early:
if(strlen(prefix) + strlen(port) + 1 > sizeof(portFullName)){
return (jlong)((HANDLE)jssc_SerialNativeInterface_ERR_PORT_NOT_FOUND);
}port is still held here, so an overlong port name leaks the acquired chars on
every call — reachable with an ordinary Java string, no OOM required.
GetStringUTFChars() can also return NULL (typically with OutOfMemoryError
pending). The result is used immediately by strlen(port) with no null check, so
on acquisition failure the code dereferences NULL and can crash the process
instead of propagating the exception.
Suggested fix: check the result for NULL right after acquisition, and release
port before the early return on the length-check path.
I found a possible JNI string leak and an unchecked-null dereference in the Windows implementation of
openPort().File:
src/main/cpp/windows/jssc.cppFunction:
Java_jssc_SerialNativeInterface_openPortRelevant code:
GetStringUTFChars()returns a native string that must be paired withReleaseStringUTFChars(). The only release is afterCreateFile(), but thelength-check path returns early:
portis still held here, so an overlong port name leaks the acquired chars onevery call — reachable with an ordinary Java string, no OOM required.
GetStringUTFChars()can also returnNULL(typically withOutOfMemoryErrorpending). The result is used immediately by
strlen(port)with no null check, soon acquisition failure the code dereferences
NULLand can crash the processinstead of propagating the exception.
Suggested fix: check the result for
NULLright after acquisition, and releaseportbefore the early return on the length-check path.