Conversation
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Datron
force-pushed
the
rustyscript-functions
branch
from
0481b56 to
ed56c9a
Compare
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| let tags = parse_config_tags(custom_headers.config_tags)?; | ||
|
|
||
| // ── Phase 1: async validation & preparation ── | ||
| let mut prepared_ops = Vec::with_capacity(ops.len()); |
Check failure
Code scanning / CodeQL
Uncontrolled allocation size High
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI 5 days ago
In general, the way to fix this is to enforce a hard upper bound on the number of operations a client can submit in one request and abort the request if that bound is exceeded, before allocating or processing the data. That ensures that any allocations derived from ops.len() are bounded and cannot be driven arbitrarily high by an attacker. Since with_capacity itself is not problematic when given a safe bound, we can keep the preallocation but guard its input first.
Concretely, in bulk_operations_handler in crates/context_aware_config/src/api/context/handlers.rs, we should introduce a constant such as MAX_BULK_OPERATIONS: usize = 10_000; (or whatever is appropriate for this service). After determining ops from req and before calling Vec::with_capacity(ops.len()), we check ops.len(). If it exceeds the maximum, we return an appropriate error response (for example, HTTP 413 Payload Too Large or 400 Bad Request) instead of proceeding. This keeps the existing behaviour for valid‑sized requests and prevents uncontrolled allocation for oversized requests. The only code changes required are: adding a constant definition in this file, adding a length check on ops in bulk_operations_handler, and leaving Vec::with_capacity as is but now safely bounded.
| @@ -613,6 +613,8 @@ | ||
| }, | ||
| } | ||
|
|
||
| const MAX_BULK_OPERATIONS: usize = 10_000; | ||
|
|
||
| #[authorized] | ||
| #[put("/bulk-operations")] | ||
| async fn bulk_operations_handler( | ||
| @@ -637,6 +639,17 @@ | ||
| // Marking immutable. | ||
| let is_v2 = is_v2; | ||
|
|
||
| if ops.len() > MAX_BULK_OPERATIONS { | ||
| return Err(superposition::Error::BadRequest( | ||
| format!( | ||
| "Too many bulk operations: {}, maximum allowed is {}", | ||
| ops.len(), | ||
| MAX_BULK_OPERATIONS | ||
| ) | ||
| .into(), | ||
| )); | ||
| } | ||
|
|
||
| let tags = parse_config_tags(custom_headers.config_tags)?; | ||
|
|
||
| // ── Phase 1: async validation & preparation ── |
1 participant
Problem
Describe the problem you are trying to solve here
Solution
Provide a brief summary of your solution so that reviewers can understand your code
Environment variable changes
What ENVs need to be added or changed
Pre-deployment activity
Things needed to be done before deploying this change (if any)
Post-deployment activity
Things needed to be done after deploying this change (if any)
API changes
Possible Issues in the future
Describe any possible issues that could occur because of this change