Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
fix: Limit recursion depth for unknown field detection and unpack any #22901
fix: Limit recursion depth for unknown field detection and unpack any #22901
Changes from 5 commits
bb27d7c
60c69bb
0f441f8
26bbd4b
fc8d8e1
0cc4eb3
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
🛠️ Refactor suggestion
Update limit checks to handle non-positive values
The current checks for
maxDepth
andmaxCalls.count
only handle zero values. To enhance robustness and prevent potential underflows, consider updating the conditions to check for less than or equal to zero.Apply this diff:
📝 Committable suggestion
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.
🛠️ Refactor suggestion
Prevent
maxCalls.count
from becoming negativeAfter decrementing
r.maxCalls.count
, ensure it does not become negative, which could lead to incorrect behavior. Consider adding a check after the decrement.Apply this diff:
Alternatively, since the limit check has been updated to handle non-positive values, this might already be addressed.
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.
🛠️ Refactor suggestion
Update recursion limit check to handle non-positive values
To prevent potential underflows and enhance robustness, consider updating the recursion limit check from
recursionLimit == 0
torecursionLimit <= 0
.Apply this diff:
📝 Committable suggestion
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.
🛠️ Refactor suggestion
Ensure proper handling of recursion limit during recursive calls
When recursively calling
doRejectUnknownFields
, ensure that the decrementing ofrecursionLimit
does not result in negative values, which could bypass termination conditions.Consider verifying that
recursionLimit
is greater than zero before the recursive call or rely on the updated recursion limit check as previously suggested.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.
🛠️ Refactor suggestion
Define recursion limit as a constant for maintainability
Currently, the recursion limit of
10,000
is hardcoded within theRejectUnknownFields
function. Defining this value as a constant improves readability and makes it easier to manage or adjust in the future.Apply this diff to define the recursion limit as a constant:
📝 Committable suggestion
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.
🛠️ Refactor suggestion
Update recursion limit check to handle non-positive values
The current recursion limit check only handles the case when
recursionLimit
equals zero. To prevent potential underflows and enhance robustness, consider updating the condition to check for less than or equal to zero.Apply this diff:
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.
🛠️ Refactor suggestion
Ensure decrementing recursion limit does not cause underflow
When recursively calling
doRejectUnknownFields
, ensure that decrementingrecursionLimit
does not result in negative values, which could bypass the termination condition.Consider verifying that
recursionLimit
is greater than zero before the recursive call:Alternatively, ensure the recursion limit check at the beginning of the function handles non-positive values as previously suggested.
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.
🛠️ Refactor suggestion
Consistent recursion limit handling in recursive calls
Similar to the previous comment, ensure that all recursive calls to
doRejectUnknownFields
properly handle the decrementing ofrecursionLimit
and prevent potential underflow.Apply this diff:
Ensure that the recursive function handles
recursionLimit <= 0
appropriately, as previously suggested.