JDK-8224181 : On child process spawn, child may write to random file descriptor instead of the fail pipe
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 11,12,13
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-05-20
  • Updated: 2020-01-03
  • Resolved: 2019-06-05
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
11.0.5Fixed 13 b24Fixed 14Fixed
Related Reports
Relates :  
JDK-8223777 - In posix_spawn mode, failing to exec() jspawnhelper may not result in an error
Description
While working on JDK-8223777, I spotted (childstuff.c) the following problem:

In error handling code (WhyCantJonnyExec) child signals error to parent by writing an error code to the fail pipe. It does that using the hard wired fail pipe write-end fd (FAIL_FILENO, usually 4). But that only works as intended after the fail pipe write end has been successfully dup2'ed to FAIL_FILENO.

If an error happens before that, error code will still be written to FAIL_FILENO, which may be an invalid file handle - which is almost benign - or refer to an unrelated file descriptor the child inherited and did not close yet - which is not good.
Comments
Fix Request: Important to fix because: In rare cases may lead to spurious data being written to innocent file handles. This would be almost impossible to attribute to Runtime.exec. Nature of fix: Always use the correct file handle to report back to the parent process. Low risk because: Fix is small and simple. Testing done: SAP internal nightlies (JCK, jtreg, gtests, internal stress tests.)
13-06-2019