Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JDK-8263558: Possible NULL dereference in fast path arena free if ZapResourceArea is true #2995

Closed

Conversation

@tstuefe
Copy link
Member

@tstuefe tstuefe commented Mar 14, 2021

Sonarcloud reports a possible NULL dereference when zapping the to-be-freed area in fast-path arena free. Possible call stack for this to happen starts in Node::destruct(PhaseValues* phase).


Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed

Issue

  • JDK-8263558: Possible NULL dereference in fast path arena free if ZapResourceArea is true

Reviewers

Download

To checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/2995/head:pull/2995
$ git checkout pull/2995

To update a local copy of the PR:
$ git checkout pull/2995
$ git pull https://git.openjdk.java.net/jdk pull/2995/head

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Mar 14, 2021

👋 Welcome back stuefe! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

Loading

@openjdk
Copy link

@openjdk openjdk bot commented Mar 14, 2021

@tstuefe The following label will be automatically applied to this pull request:

  • hotspot-runtime

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

Loading

@tstuefe tstuefe marked this pull request as ready for review Mar 14, 2021
@openjdk openjdk bot added the rfr label Mar 14, 2021
@mlbridge
Copy link

@mlbridge mlbridge bot commented Mar 14, 2021

Loading

@@ -185,7 +185,9 @@ class Arena : public CHeapObj<mtNone> {
// Fast delete in area. Common case is: NOP (except for storage reclaimed)
bool Afree(void *ptr, size_t size) {
#ifdef ASSERT
if (ZapResourceArea) memset(ptr, badResourceValue, size); // zap freed memory
if (ZapResourceArea && ptr != NULL) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The pointer arithmetic on line 193 is UB if ptr is nullptr (though it's unlikely anyone checks), so either Afree has ptr != nullptr as an (unstated) precondition or there are potentially more problems than the memset.

Loading

@tstuefe
Copy link
Member Author

@tstuefe tstuefe commented Mar 15, 2021

Thanks Kim. I changed the fix to fix the one caller I was sure about passing NULL, and assert in AFree instead.

(update: looking at Node::destruct, I believe the coding was correct and there is no way this could have been called with NULL; so I reduce this patch to just the assert in AFree)

I removed the Trivial mark. Before pushing I will put this through tests to check if it triggers. I believe even though the pointer arithmetic below was UB with NULL, the effect would have in general been benign (just refusing to free anything).

Loading

@openjdk
Copy link

@openjdk openjdk bot commented Mar 15, 2021

@tstuefe This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8263558: Possible NULL dereference in fast path arena free if ZapResourceArea is true

Reviewed-by: kbarrett, coleenp

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 114 new commits pushed to the master branch:

  • 5b8233b: 8263871: On sem_destroy() failing we should assert
  • 96e5c3f: 8263890: Broken links to Unicode.org
  • 4d9517d: 8263834: Work around gdb for HashtableEntry
  • 6fa6557: 8263825: Remove unused and commented out member from NTLMException
  • 77ebc11: 8263892: More modifier order fixes in java.base
  • 80d3ea0: 8263885: Use the blessed modifier order in java.sql/rowset/transation.xa
  • 6737135: 8262083: vmTestbase/nsk/jvmti/SetEventNotificationMode/setnotif001/TestDescription.java failed with "No notification: event JVMTI_EVENT_FRAME_POP (61)"
  • 57fc8e9: 8262080: vmTestbase/nsk/jdi/Event/request/request001/TestDescription.java failed with "ERROR: new event is not ThreadStartEvent"
  • 0b5216a: 8263545: Convert jpackage to use Stream.toList()
  • ed701ea: 8262271: SA: Add new stress test that tests getting the stack trace of an active thread
  • ... and 104 more: https://git.openjdk.java.net/jdk/compare/9c84899da4689b395d0089e6cb777cb50cd3e547...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

Loading

@openjdk openjdk bot added the ready label Mar 15, 2021
@mlbridge
Copy link

@mlbridge mlbridge bot commented Mar 15, 2021

Mailing list message from Kim Barrett on hotspot-runtime-dev:

On Mar 15, 2021, at 1:59 AM, Thomas Stuefe <stuefe at openjdk.java.net> wrote:

On Sun, 14 Mar 2021 06:09:26 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

Sonarcloud reports a possible NULL dereference when zapping the to-be-freed area in fast-path arena free. Possible call stack for this to happen starts in Node::destruct(PhaseValues* phase).

Thanks Kim. I changed the fix to fix the one caller I was sure about passing NULL, and assert in AFree instead.

(The skara bots don?t resend edited comments, so this is missing your update, quoted below.)

(update: looking at Node::destruct, I believe the coding was correct and there is no way this could have been called with NULL; so I reduce this patch to just the assert in AFree)

I looked at it too, and agree with your assessment.

I removed the Trivial mark. Before pushing I will put this through tests to check if it triggers. I believe even though the pointer arithmetic below was UB with NULL, the effect would have in general been benign (just refusing to free anything).

I also agree the UB won?t be detected and the effect benign.

Looks good.

Loading

@tstuefe
Copy link
Member Author

@tstuefe tstuefe commented Mar 15, 2021

Mailing list message from Kim Barrett on hotspot-runtime-dev:

Looks good.

Thanks Kim.

Loading

Copy link
Contributor

@coleenp coleenp left a comment

Looks good.

Loading

@tstuefe
Copy link
Member Author

@tstuefe tstuefe commented Mar 16, 2021

Thanks @coleenp and @kimbarrett . However, as I feared, with the assert alone I now see it firing both in our nightlies at SAP and in the GAs in compiler tests.

Which is cool in a way since this is the first time SonarCloud reported anything demonstrably real.:) I'll take a look at the crashes and modify the patch.

Loading

@tstuefe
Copy link
Member Author

@tstuefe tstuefe commented Mar 16, 2021

I changed the patch to provide the same semantics on passed old ptr == NULL as standard free(3) and realloc(3) have. Which is to ignore it (free) or to revert to malloc (realloc).

The culprit in this case - calling realloc with a NULL pointer - was aot, ImplicitExceptionTable::append( uint exec_off, uint cont_off ).

I considered fixing the caller, but I am used to the C-runtime semantics in free and realloc, and it looks like others are too; so this is the least surprising behavior for a realloc-like function.

Also, this fixes the subtle bug where, when passing NULL to Arealloc, we would return "false" to indicate that we have a lossfull realloc. The only case I can see where the return value was actually used was in SymbolTable::delete_symbol() which would print something about leaked symbols in that case. I did not investigate whether this has any practical relevance.

Loading

@tstuefe
Copy link
Member Author

@tstuefe tstuefe commented Mar 17, 2021

Coleen, Kim, are you fine with this latest version? Thanks!

Loading

@@ -366,6 +366,10 @@ void* Arena::grow(size_t x, AllocFailType alloc_failmode) {
// Reallocate storage in Arena.
void *Arena::Arealloc(void* old_ptr, size_t old_size, size_t new_size, AllocFailType alloc_failmode) {
if (new_size == 0) return NULL;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[pre-existing] Isn't this a leak? Probably just dropping old_ptr.

Loading

Copy link
Member Author

@tstuefe tstuefe Mar 18, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it is a leak, at least if we run with UseMallocOnly. I think this, and Amalloc, should behave consistently with os::malloc here, which is to return a small non-null allocation for size=0. Basically, if size==0 size=1.

Loading

src/hotspot/share/memory/arena.cpp Show resolved Hide resolved
Loading
Copy link

@kimbarrett kimbarrett left a comment

Looks good.

Loading

@tstuefe
Copy link
Member Author

@tstuefe tstuefe commented Mar 20, 2021

Thanks Coleen & Kim!

/integrate

Loading

@openjdk openjdk bot closed this Mar 20, 2021
@openjdk openjdk bot added integrated and removed ready rfr labels Mar 20, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Mar 20, 2021

@tstuefe Since your change was applied there have been 115 commits pushed to the master branch:

  • ab66d69: 8263138: Initialization of sun.font.SunFontManager.platformFontMap is not thread safe
  • 5b8233b: 8263871: On sem_destroy() failing we should assert
  • 96e5c3f: 8263890: Broken links to Unicode.org
  • 4d9517d: 8263834: Work around gdb for HashtableEntry
  • 6fa6557: 8263825: Remove unused and commented out member from NTLMException
  • 77ebc11: 8263892: More modifier order fixes in java.base
  • 80d3ea0: 8263885: Use the blessed modifier order in java.sql/rowset/transation.xa
  • 6737135: 8262083: vmTestbase/nsk/jvmti/SetEventNotificationMode/setnotif001/TestDescription.java failed with "No notification: event JVMTI_EVENT_FRAME_POP (61)"
  • 57fc8e9: 8262080: vmTestbase/nsk/jdi/Event/request/request001/TestDescription.java failed with "ERROR: new event is not ThreadStartEvent"
  • 0b5216a: 8263545: Convert jpackage to use Stream.toList()
  • ... and 105 more: https://git.openjdk.java.net/jdk/compare/9c84899da4689b395d0089e6cb777cb50cd3e547...master

Your commit was automatically rebased without conflicts.

Pushed as commit d2c137d.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

Loading

@tstuefe tstuefe deleted the JDK-8263558-Arena-afree-null-deref branch Apr 26, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants