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-8298248: Limit sscanf output width in cgroup file parsers #11554

Closed

Conversation

tstuefe
Copy link
Member

@tstuefe tstuefe commented Dec 7, 2022

Trivial.

GET_CONTAINER_INFO_CPTR should be called with limits for the output buffers. The usual 1K provided should be large enough normally. This just prevents intentionally malformed input from causing overwriters.


Progress

  • Change must be properly reviewed (1 review required, with at least 1 Reviewer)
  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue

Issue

  • JDK-8298248: Limit sscanf output width in cgroup file parsers

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/11554/head:pull/11554
$ git checkout pull/11554

Update a local copy of the PR:
$ git checkout pull/11554
$ git pull https://git.openjdk.org/jdk pull/11554/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 11554

View PR using the GUI difftool:
$ git pr show -t 11554

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/11554.diff

@bridgekeeper
Copy link

bridgekeeper bot commented Dec 7, 2022

👋 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.

@openjdk
Copy link

openjdk bot commented Dec 7, 2022

@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.

@openjdk openjdk bot added the hotspot-runtime hotspot-runtime-dev@openjdk.org label Dec 7, 2022
@tstuefe tstuefe marked this pull request as ready for review December 7, 2022 08:23
@openjdk openjdk bot added the rfr Pull request is ready for review label Dec 7, 2022
@mlbridge
Copy link

mlbridge bot commented Dec 7, 2022

Webrevs

Copy link
Member

@dholmes-ora dholmes-ora left a comment

Choose a reason for hiding this comment

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

This doesn't give me a good feeling - the 1023 is 1024-1 but the two are completely independent as expressed. Ideally this would be handled inside the macro but that in turn passes things to subsystem_file_line_contents and so there is no easy way to express that the width limit is related to the bufsize. :(

So I reluctantly approve.

@openjdk
Copy link

openjdk bot commented Dec 7, 2022

@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:

8298248: Limit sscanf output width in cgroup file parsers

Reviewed-by: dholmes, sgehwolf

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 7 new commits pushed to the master branch:

  • 4da8411: 8298108: Add a regression test for JDK-8297684
  • 80cbfab: 8298169: Remove unused methods in space.hpp
  • 221e1a4: 8286666: JEP 429: Implementation of Scoped Values (Incubator)
  • ccc69af: 8296672: Implementation of Virtual Threads (Second Preview)
  • 5a3439d: 4677581: ColorModel.getComponentSize()-wrong conditions for ArrayIndexOutOfBoundsExceptio
  • 27bbe7b: 8297976: Remove sun.net.ProgressMonitor and related classes
  • 085f96c: 8295258: Add BasicType argument to AccessInternal::decorator_fixup

Please see this link for an up-to-date comparison between the source branch of this pull request and the master branch.
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.

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Dec 7, 2022
@tstuefe
Copy link
Member Author

tstuefe commented Dec 7, 2022

This doesn't give me a good feeling - the 1023 is 1024-1 but the two are completely independent as expressed. Ideally this would be handled inside the macro but that in turn passes things to subsystem_file_line_contents and so there is no easy way to express that the width limit is related to the bufsize. :(

So I reluctantly approve.

Yes, this also bugged me. Specifying buffer size twice, with -1 offset no less, seems error-prone. The thing is that the format specifier handed in is not always just "%s", sometimes its more, with suppressed matchers (e.g. "%s %*d").

With the explicit width specifiers I followed what other incarnations of this macro already do, so I did not make it worse. A code revamp would be certainly nice.

@openjdk openjdk bot removed the ready Pull request is ready to be integrated label Dec 7, 2022
@jerboaa
Copy link
Contributor

jerboaa commented Dec 7, 2022

With the explicit width specifiers I followed what other incarnations of this macro already do, so I did not make it worse. A code revamp would be certainly nice.

Yes agreed. Those macros are a bit dangerous. Recently, when I looked into JDK-8297274 there was another oddity that stood out. Reading values in as julong and then casting them to jlong :-/

@tstuefe
Copy link
Member Author

tstuefe commented Dec 7, 2022

/integrate

@openjdk
Copy link

openjdk bot commented Dec 7, 2022

@tstuefe This pull request has not yet been marked as ready for integration.

@jerboaa
Copy link
Contributor

jerboaa commented Dec 7, 2022

@tstuefe Sorry, I changed the typo in the bug synopsis. Please change it in the PR title and the ready label should appear again.

@tstuefe tstuefe changed the title JDK-8298248: Limit sscanf outbut width in cgroup file parsers JDK-8298248: Limit sscanf output width in cgroup file parsers Dec 7, 2022
@tstuefe
Copy link
Member Author

tstuefe commented Dec 7, 2022

@jerboaa I had to look close to spot it :-)

/integrate

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Dec 7, 2022
@openjdk
Copy link

openjdk bot commented Dec 7, 2022

Going to push as commit 3e041eb.
Since your change was applied there have been 7 commits pushed to the master branch:

  • 4da8411: 8298108: Add a regression test for JDK-8297684
  • 80cbfab: 8298169: Remove unused methods in space.hpp
  • 221e1a4: 8286666: JEP 429: Implementation of Scoped Values (Incubator)
  • ccc69af: 8296672: Implementation of Virtual Threads (Second Preview)
  • 5a3439d: 4677581: ColorModel.getComponentSize()-wrong conditions for ArrayIndexOutOfBoundsExceptio
  • 27bbe7b: 8297976: Remove sun.net.ProgressMonitor and related classes
  • 085f96c: 8295258: Add BasicType argument to AccessInternal::decorator_fixup

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label Dec 7, 2022
@openjdk openjdk bot closed this Dec 7, 2022
@openjdk openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Dec 7, 2022
@openjdk
Copy link

openjdk bot commented Dec 7, 2022

@tstuefe Pushed as commit 3e041eb.

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

@jdksjolen
Copy link
Contributor

This doesn't look right at all from the beginning.. Look at this PR I just created: #11557

@jdksjolen
Copy link
Contributor

OK, I was a bit too quick. Yes, this is correct, except for the last line:

                "Maximum number of tasks is: %s", "%1023s %*d", pidsmax, 1024);

Where the bug is the same as in the PR I just created.

@tstuefe tstuefe deleted the JDK-8298248-cgroup-sscanf-limit branch February 15, 2023 06:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hotspot-runtime hotspot-runtime-dev@openjdk.org integrated Pull request has been integrated
4 participants