JDK-8229378 : jdwp library loader in linker_md.c quietly truncates on buffer overflow
  • Type: Bug
  • Component: core-svc
  • Sub-Component: debugger
  • Affected Version: 8,11,13
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-08-09
  • Updated: 2020-11-12
  • Resolved: 2019-09-11
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 11 JDK 13 JDK 14 Other
11.0.9-oracleFixed 13.0.6Fixed 14 b15Fixed openjdk8u272Fixed
Description
Known bug (documented in code comment) quietly truncates when the buffer length is less than the path string plus the length of the file name (plus 10).

This is a problem for three main reasons:
1) This should be an error. It isn't one.
2) The current form outputs no useful debug information.
3) The path string can contain multiple paths, and we act based on the length *before* chopping it into individual paths. So if we have two strings of length: 300, and a maximum buffer size of 400, we act as if there's something wrong.

To solve all three issues, I've created a webrev with a fix.

IMPORTANT NOTE: the os.cpp change is only to enable testing. This will NOT be included in the final webrev. I added the os.cpp bit because right now the parameter that provokes a failure in the dll_build_name function (the one that handles multiple paths) causes failure in os.cpp when it loads libraries during startup. Still changing dll_build_name because I don't think we should be relying on os.cpp behaviour.

Testing:

Step 1: Apply changes and build
Step 2: export LONGPATH="/aaaaaaa" (continue aaaaas for 5000 characters) 
Step 3: rename the libdtsocket.so file to something else, or just move it.
This means that the relevant code won't find the library in the default path, and will iterate through alternate paths to find it.
Step 4: Run this to test the fix: java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n -Dsun.boot.library.path=$LONGPATH TestClass
(Where TestClass does nothing. Can print a message to show it ran.)
Step 5: watch as new, useful error message is produced.

Webrev: http://cr.openjdk.java.net/~afarley/8229378/webrev/
Comments
Fix request (13u): I'd like to port it to 13u, too. The patch applies cleanly, and I'm trying to use new Skara backport workflow for this one.
03-11-2020
Thanks Andrew and Severin.
19-06-2020
Thanks for the input Adam. I agree with Andrew. The risk is fairly low and it's in the debugger code which shouldn't affect general use. Approving for 8u272.
17-06-2020
I think the risks of including this are incredibly low, so I'm inclined to approve, unless there is a more substantial objection. I do think it should go into 11u first, for which it has also been approved. Note that for 8u, the near exact same code is also present in hprof_md.c, so a similar bug & fix should be made for that.
16-06-2020
Heya Severin, If I recall correctly, the *actual* bug was just the first "main reason". When you're running on Windows with your jdk deep enough into the path, we end up silently failing to find the .so file, and the error message you get ends up being incorrect. "Could not open lib" rather than "your paths are messed up". By fixing this problem the proposed way, not only do you get a useful error message, but we also cover our bases if a library isn't in the default location. The latter is unlikely, I agree. Still, it's worth including the change if only for the useful error message on Windows.
16-06-2020
[~afarley] Step 3 in the bug description suggests this only happens if libdt_socket.so is not in a default path, right? If so it seems a corner case which I'm inclined to reject for 8u. Please clarify whether or not this is an issue with default libdt_socket.so as well.
16-06-2020
Fix Request Request to backport this patch to 11u and 8u. Note that the file locations change for 8u, but the relevant contents appear the same. changeset: https://hg.openjdk.java.net/jdk/jdk/rev/b00b4706ec0f Home builds imply changeset applies cleanly.
01-06-2020
URL: https://hg.openjdk.java.net/jdk/jdk/rev/b00b4706ec0f User: sspitsyn Date: 2019-09-11 23:10:38 +0000
11-09-2019
Build finished on Friday, and the test passed today. Will notify the serviceability mailing list for review.
12-08-2019
Fix verified on Unix with the test in description. Build still running for Windows.
09-08-2019
Seems a simple problem and fix. We only need consensus on the form of the fix.
09-08-2019