-
Notifications
You must be signed in to change notification settings - Fork 4k
GH-48900: [C++] Avoid memory blowup with excessive variadic buffer count in IPC #48901
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
e3d44d5 to
45e4584
Compare
|
@github-actions crossbow submit -g cpp |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
The failure on the ASAN CI job is because #48859 needs to be merged. |
45e4584 to
76d9280
Compare
|
@github-actions crossbow submit -g cpp |
This comment was marked as outdated.
This comment was marked as outdated.
76d9280 to
a600573
Compare
|
@github-actions crossbow submit -g cpp |
|
Rebased, I'll merge if CI is green. Thanks for the review @WillAyd ! |
|
Revision: a600573 Submitted crossbow builds: ursacomputing/crossbow @ actions-23dc77869a |
|
After merging your PR, Conbench analyzed the 3 benchmarking runs that have been run so far on merge-commit 421a475. There were no benchmark performance regressions. 🎉 The full Conbench report has more details. It also includes information about 2 possible false positives for unstable benchmarks that are known to sometimes produce them. |
Rationale for this change
An incorrect variadic buffer count could easily blow up memory when reserving a vector of Buffers, even though the RecordBatch has a lot less buffers available.
Reported by OSS-Fuzz at https://issues.oss-fuzz.com/issues/476180608, and separately by Silas Boch.
What changes are included in this PR?
Pre-validate the variadic buffer count read from the IPC RecordBatch table. Initial patch by Silas Boch.
Are these changes tested?
Yes, by additional fuzz regression file.
Are there any user-facing changes?
No.
This PR contains a "Critical Fix". (If the changes fix either (a) a security vulnerability, (b) a bug that caused incorrect or invalid data to be produced, or (c) a bug that causes a crash (even when the API contract is upheld), please provide explanation. If not, you can remove this.)