On Wed, 24 May 2023 15:22:15 GMT, Maurizio Cimadamore <mcimadam...@openjdk.org> wrote:
> There is a difference in behavior between `System::loadLibrary` and > `SymbolLookup::libraryLookup(String)`. While the former catches library names > containing NULL chars (because, internally it uses Path/File logic, which > reject those), `SymbolLookup` does not. As a result, it is possible to load > libraries such as `libGL.so\0foobar`, because the string is passed directly > to `dlopen`. > > A similar issue arises when we consider `SymbolLookup::find`, as the name is > again sent unmodified to `dlopen`. In reality, some filtering *does* happen > in that case, as the native code calls `GetStringUTFChars`: > > https://docs.oracle.com/en/java/javase/20/docs/specs/jni/functions.html#getstringutfchars > > Which encodes the NULL chars in a different form: > > https://docs.oracle.com/en/java/javase/20/docs/specs/jni/types.html#modified-utf-8-strings > > So, in practice, even if the input is not validated, a call to `find` with > one or more NULL chars is unlikely to succeed. > > In this patch I have added several checks to make sure that: > * the name of library passed to `libraryLookup(String)` does not contain `\0` > and, if so, throw `IllegalArgumentException` (which is already covered by > current spec; > * the name of a symbol passed to `SymbolLookup::find` does not contain `\0` > and, if so, return empty optional. This required changes on all the lookups > we implement. This pull request has now been integrated. Changeset: 534de6d8 Author: Maurizio Cimadamore <mcimadam...@openjdk.org> URL: https://git.openjdk.org/jdk/commit/534de6d8ae8a241562ffae002a96e40c1ae0b015 Stats: 38 lines in 6 files changed: 38 ins; 0 del; 0 mod 8300491: SymbolLookup::libraryLookup accepts strings with terminators Reviewed-by: psandoz ------------- PR: https://git.openjdk.org/jdk/pull/14126
