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

ICU-22897 Fix memory leak and int overflow #3181

Merged
merged 1 commit into from
Sep 18, 2024

Conversation

FrankYFTang
Copy link
Contributor

@FrankYFTang FrankYFTang commented Sep 18, 2024

  1. Rewrite to use LocalPointer to prevent memory leak
  2. Rewrite the if/else to switch to make the logic clear
  3. Delete the rule if not remember inside the rule set to fix memory leak.
  4. Check base value calculation to avoid int64_t overflow.
  5. Add memory leak test
Checklist
  • Required: Issue filed: https://unicode-org.atlassian.net/browse/ICU-22897
  • Required: The PR title must be prefixed with a JIRA Issue number.
  • Required: The PR description must include the link to the Jira Issue, for example by completing the URL in the first checklist item
  • Required: Each commit message must be prefixed with a JIRA Issue number.
  • Issue accepted (done by Technical Committee after discussion)
  • Tests included, if applicable
  • API docs and/or User Guide docs changed or added, if applicable

1. Rewrite to use LocalPointer to prevent memory leak
2. Rewrite the if/else to switch to make the logic clear
3. Delete the rule if not remember inside the rule set to fix memory
leak.
4. Check base value calculation to avoid int64_t overflow.
5. Add memory leak test
@FrankYFTang FrankYFTang requested review from richgillam, roubert and grhoten and removed request for roubert September 18, 2024 20:54
Copy link
Contributor

@richgillam richgillam left a comment

Choose a reason for hiding this comment

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

This all looks reasonable...

@FrankYFTang FrankYFTang merged commit 303b7e8 into unicode-org:main Sep 18, 2024
94 checks passed
@FrankYFTang FrankYFTang deleted the ICU-22897-NFParserLeak branch September 18, 2024 21:40
Comment on lines 290 to +300
while (p < descriptorLength) {
c = descriptor.charAt(p);
if (c >= gZero && c <= gNine) {
val = val * ll_10 + static_cast<int32_t>(c - gZero);
int32_t single_digit = static_cast<int32_t>(c - gZero);
if ((val > 0 && val > (std::numeric_limits<int64_t>::max() - single_digit) / 10) ||
(val < 0 && val < (std::numeric_limits<int64_t>::min() - single_digit) / 10)) {
// out of int64_t range
status = U_PARSE_ERROR;
return;
}
val = val * ll_10 + single_digit;
Copy link
Member

Choose a reason for hiding this comment

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

Why is the math being done inconsistently here. Why are we using 10 for part of the math and ll_10 for another part of the math?

Where is the test for this if statement? I only see a test for the memory leak.

Wouldn't it be just as easy to check if the sign flipped instead of redundantly performing this math?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The memory leak test will also cause the usan report int overflow
The sign flipped will happen after int overflow and will cause usan report the error

Copy link
Member

Choose a reason for hiding this comment

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

Isn't this issue applicable to Java too? This check should be kept in sync with ICU4J.

Can you please use and/or rename ll_10 too? I'm not a fan of magic numbers. The rules are base 10, and it would be helpful to the next maintainer to be more descriptive on why 10 is used.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants