JDK-8275846 : read_base_archive_name() could read past the end of buffer
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 18
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • CPU: x86_64
  • Submitted: 2021-10-24
  • Updated: 2021-11-07
  • Resolved: 2021-11-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 18
18 masterFixed
Related Reports
Duplicate :  
JDK-8276625 - runtime/cds/appcds/dynamicArchive/ArchiveConsistency.java fails with assert(result == unicode_path_len) failed: length already checked above
Duplicate :  
JDK-8261455 - Automatically generate the CDS archive if necessary
Relates :  
JDK-8276769 - -Xshare:auto should tolerate problems in the CDS archive
Description
Test: runtime/cds/appcds/dynamicArchive/ArchiveConsistency.java

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (t:\workspace\open\src\hotspot\os\windows\os_windows.cpp:4435), pid=73956, tid=58200
#  assert(result == unicode_path_len) failed: length already checked above
#

---------------  T H R E A D  ---------------

Current thread is native thread

Stack: [0x0000000856d00000,0x0000000856e00000]
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0xb532f1]  os::platform_print_native_stack+0xf1  (os_windows_x86.cpp:235)
V  [jvm.dll+0xd9047e]  VMError::report+0x101e  (vmError.cpp:828)
V  [jvm.dll+0xd91e7e]  VMError::report_and_die+0x7fe  (vmError.cpp:1656)
V  [jvm.dll+0xd92604]  VMError::report_and_die+0x64  (vmError.cpp:1437)
V  [jvm.dll+0x4df6c7]  report_vm_error+0xb7  (debug.cpp:282)
V  [jvm.dll+0xb4982d]  convert_to_unicode+0x9d  (os_windows.cpp:4435)
V  [jvm.dll+0xb52a27]  wide_abs_unc_path+0x117  (os_windows.cpp:4500)
V  [jvm.dll+0xb51a0a]  os::stat+0x3a  (os_windows.cpp:4538)
V  [jvm.dll+0xb40988]  os::file_exists+0x48  (os.cpp:1403)
V  [jvm.dll+0x596082]  FileHeaderHelper::read_base_archive_name+0xe2  (filemap.cpp:1098)
V  [jvm.dll+0x592c75]  FileMapInfo::check_archive+0x1f5  (filemap.cpp:1143)
V  [jvm.dll+0x227a15]  Arguments::init_shared_archive_paths+0x3c5  (arguments.cpp:3542)
V  [jvm.dll+0x226115]  Arguments::apply_ergo+0x205  (arguments.cpp:4001)
V  [jvm.dll+0xd0a7b2]  Threads::create_vm+0xf2  (thread.cpp:2709)
V  [jvm.dll+0x7ac892]  JNI_CreateJavaVM_inner+0xb2  (jni.cpp:3616)
V  [jvm.dll+0x7b01ef]  JNI_CreateJavaVM+0x1f  (jni.cpp:3704)
Comments
Changeset: 88491549 Author: Ioi Lam <iklam@openjdk.org> Date: 2021-11-07 21:38:59 +0000 URL: https://git.openjdk.java.net/jdk/commit/884915496f7bfe754279f1644603131c64f192b3
07-11-2021
JDK-8261455 may take longer to integrate than expected. Let's do a small fix for this crash first.
05-11-2021
This is addressed in jdk-8261455. This closed as dup.
27-10-2021
ILW = HLM = P3
26-10-2021
The bug seems to be here: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/cds/filemap.cpp#L1092 size_t n = os::read(_fd, *target, (unsigned int)name_size); if (n != name_size) { log_info(cds)("Unable to read base archive name from archive"); FREE_C_HEAP_ARRAY(char, *target); return false; } if (!os::file_exists(*target)) { <<<<<<<<<<<<< here In this test case, the name is not zero-terminated, so os::file_exists(*target) will be passing a string whose end is in the unallocated area of the C heap. When the following code is executed in os_windows.cpp, if a C_HEAP_ALLOC happens between the two MultiByteToWideChar calls, the string pointed to by char_path will change, and hence result will not be equal to unicode_path_len. =============== static errno_t convert_to_unicode(char const* char_path, LPWSTR* unicode_path) { // Get required buffer size to convert to Unicode int unicode_path_len = MultiByteToWideChar(CP_ACP, MB_ERR_INVALID_CHARS, char_path, -1, NULL, 0); if (unicode_path_len == 0) { return EINVAL; } /////// <<<<<<<<<<<<<<<<< C_HEAP_ALLOC happens in a different thread *unicode_path = NEW_C_HEAP_ARRAY(WCHAR, unicode_path_len, mtInternal); int result = MultiByteToWideChar(CP_ACP, MB_ERR_INVALID_CHARS, char_path, -1, *unicode_path, unicode_path_len); assert(result == unicode_path_len, "length already checked above"); ====================
26-10-2021
The mdmp doesn't give much information. Below are the threads dump using windbg: 0:000> ~*kb . 0 Id: 120e4.8a20 Suspend: 0 Teb: 00000008`56972000 Unfrozen # RetAddr : Args to Child : Call Site 00 00007ffe`861be7fe : 00000149`b14994c0 00007ffe`8778afdd 00000000`00000000 00000000`00000000 : ntdll!NtWaitForSingleObject+0x14 01 00007ffe`7992798b : 00000000`00000124 00000000`00000000 00000000`00000000 00000000`00000124 : KERNELBASE!WaitForSingleObjectEx+0x8e 02 00007ffe`7992492c : 00000000`00000000 00000149`b148e298 00000000`00000000 00000149`0000e358 : jli!CallJavaMainInNewThread+0x87 [t:\workspace\open\src\java.base\windows\native\libjli\java_md.c @ 811] 03 00007ffe`79925149 : 00000149`b1499460 00000008`56aff940 00000149`b1494f80 00000008`56aff8a0 : jli!ContinueInNewThread+0x94 [t:\workspace\open\src\java.base\share\native\libjli\java.c @ 2285] 04 00007ff7`2c9c1139 : 00007ff7`2c9c2200 00000149`b1499680 00000000`00000000 00007ffe`85eb6a36 : jli!JLI_Launch+0x4ad [t:\workspace\open\src\java.base\share\native\libjli\java.c @ 339] 05 00007ff7`2c9c13b0 : 00000149`b1499680 00007ff7`2c9c1429 00000000`00000000 00000000`00000000 : java!main+0x131 06 00007ffe`87784ed0 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : java!main+0x3a8 07 00007ffe`8890e20b : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0x10 08 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x2b 1 Id: 120e4.93ac Suspend: 0 Teb: 00000008`56974000 Unfrozen # RetAddr : Args to Child : Call Site 00 00007ffe`8889c25f : 00000000`00000000 00000000`00000000 00000149`b1484b60 00000149`b149e960 : ntdll!NtWaitForWorkViaWorkerFactory+0x14 01 00007ffe`87784ed0 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!TppWorkerThread+0x2df 02 00007ffe`8890e20b : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0x10 03 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x2b 2 Id: 120e4.6550 Suspend: 0 Teb: 00000008`56976000 Unfrozen # RetAddr : Args to Child : Call Site 00 00007ffe`8889c25f : 00000000`00000000 00000000`00000000 00000149`b1484b60 00000149`b149f340 : ntdll!NtWaitForWorkViaWorkerFactory+0x14 01 00007ffe`87784ed0 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!TppWorkerThread+0x2df 02 00007ffe`8890e20b : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0x10 03 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x2b 3 Id: 120e4.e358 Suspend: 0 Teb: 00000008`56978000 Unfrozen # RetAddr : Args to Child : Call Site 00 00000008`56df9fb8 : 00000000`00000002 00000000`00000000 000004b4`00030000 00000001`f46857d4 : ntdll!NtGetContextThread+0x14 01 00000000`00000002 : 00000000`00000000 000004b4`00030000 00000001`f46857d4 00000149`b1211764 : 0x00000008`56df9fb8 02 00000000`00000000 : 000004b4`00030000 00000001`f46857d4 00000149`b1211764 00000008`56978000 : 0x2
25-10-2021