-
Notifications
You must be signed in to change notification settings - Fork 6.1k
8339134: Callers of Exceptions::fthrow should ensure exception message lengths avoid the INT_MAX limits of os::vsnprintf #21867
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
Conversation
…e lengths avoid the INT_MAX limits of os::vsnprintf
👋 Welcome back dholmes! A progress list of the required criteria for merging this PR into |
@dholmes-ora 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:
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
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 |
@dholmes-ora The following labels will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command. |
Webrevs
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I understand the change now. Looks good.
@@ -323,6 +323,9 @@ void LinkResolver::check_klass_accessibility(Klass* ref_klass, Klass* sel_klass, | |||
char* msg = Reflection::verify_class_access_msg(ref_klass, | |||
InstanceKlass::cast(base_klass), | |||
vca_result); | |||
|
|||
// Names are all known to be < 64k so we know this formatted message is not excessively large. | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you move this comment to before the first fthrow call at 331? The other fthrow has a msg so doesn't really apply and the comment looks better as just one line like the other places.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The comment still applies to the msg created by:
char* msg = Reflection::verify_class_access_msg(ref_klass,
InstanceKlass::cast(base_klass),
vca_result);
which is also known to be limited by class name symbol lengths. That is why I placed the comment prior to both fthrow calls.
Thanks for the review @coleenp . I will re-merge and re-test then seek second review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, LGTM
Thanks for the review @jdksjolen ! /integrate |
Going to push as commit 8de158a.
Your commit was automatically rebased without conflicts. |
@dholmes-ora Pushed as commit 8de158a. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
This is mostly an audit of the callers of
Exceptions::fthrow
to ensure unbounded strings can't appear.There is a code change in DiagnosticCmd parsing to extend the string length limit already used in part of that code.
Just to clarify the issue. The size 1024 is an internal buffer limit that
fthrow
uses - it is an implementation detail and not something the caller should think about. It is also not relevant to the underlying problem, which is the size of the buffer needed for the fully expanded format string, whichos::vsnprintf
will try to calculate and report. The intent is to check callers can't hit that underlyingvsnprintf
INT_MAX limit. When your format string only deals with a few symbols and symbols are always < 64K then we know we are nowhere near that INT_MAX limit. If your format string can take a potentially arbitrary (usually from outside) string then it needs to put its own size guard in place using%*s
.Testing:
Thanks
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/21867/head:pull/21867
$ git checkout pull/21867
Update a local copy of the PR:
$ git checkout pull/21867
$ git pull https://git.openjdk.org/jdk.git pull/21867/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 21867
View PR using the GUI difftool:
$ git pr show -t 21867
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/21867.diff
Using Webrev
Link to Webrev Comment