fix: Integer overflow in range filter boundary conversion (#17216)#17216
Closed
peterenescu wants to merge 1 commit intofacebookincubator:mainfrom
Closed
fix: Integer overflow in range filter boundary conversion (#17216)#17216peterenescu wants to merge 1 commit intofacebookincubator:mainfrom
peterenescu wants to merge 1 commit intofacebookincubator:mainfrom
Conversation
✅ Deploy Preview for meta-velox canceled.
|
meta-cla
Bot
added
the
CLA Signed
|
@peterenescu has exported this pull request. If you are a Meta employee, you can view the originating Diff in D101039167. |
meta-codesync
Bot
changed the title
peterenescu
added a commit
to peterenescu/velox
that referenced
this pull request
Apr 16, 2026
…cubator#17216) Summary: When converting exclusive bounds to inclusive bounds for BigintRange, HugeintRange, and TimestampRange filters, the code unconditionally increments/decrements the boundary value. This overflows when the value is at the type limit (e.g., greaterThan(INT64_MAX) computes INT64_MAX + 1, which wraps to INT64_MIN, creating a range that matches everything instead of nothing). Guard against overflow by returning AlwaysFalse (or IsNull when nulls are allowed) when the boundary is at the type limit. This fixes incorrect query results for filters like WHERE col > 9223372036854775807. Differential Revision: D101039167
peterenescu
force-pushed
the
export-D101039167
branch
2 times, most recently
from
5217e8e to
a921885
Compare
peterenescu
added a commit
to peterenescu/velox
that referenced
this pull request
Apr 16, 2026
…cubator#17216) Summary: When converting exclusive bounds to inclusive bounds for BigintRange, HugeintRange, and TimestampRange filters, the code unconditionally increments/decrements the boundary value. This overflows when the value is at the type limit (e.g., greaterThan(INT64_MAX) computes INT64_MAX + 1, which wraps to INT64_MIN, creating a range that matches everything instead of nothing). Guard against overflow by returning AlwaysFalse (or IsNull when nulls are allowed) when the boundary is at the type limit. This fixes incorrect query results for filters like WHERE col > 9223372036854775807. Differential Revision: D101039167
CI Failure Analysis❌ Expression Fuzzer with Presto SOT — FUZZER Failure View logsFuzzer: Presto Expression Fuzzer with Presto as source of truth Error: Velox and reference DB (Presto) results don't match Correlation with PR changes:
Known issues:
Reproduce locally: ./velox_expression_fuzzer_test \
--seed 734102844 \
--enable_variadic_signatures \
--velox_fuzzer_enable_complex_types \
--lazy_vector_generation_ratio 0.2 \
--common_dictionary_wraps_generation_ratio=0.3 \
--velox_fuzzer_enable_column_reuse \
--velox_fuzzer_enable_expression_reuse \
--enable_dereference \
--duration_sec 300 \
--special_forms="cast,coalesce,if" \
--velox_fuzzer_max_level_of_nesting=1 \
--presto_url=http://127.0.0.1:8080Note: Requires a running Presto server on port 8080. Recommended action:
|
peterenescu
force-pushed
the
export-D101039167
branch
from
a921885 to
053741e
Compare
peterenescu
added a commit
to peterenescu/velox
that referenced
this pull request
Apr 17, 2026
…cubator#17216) Summary: When converting exclusive bounds to inclusive bounds for BigintRange, HugeintRange, and TimestampRange filters, the code unconditionally increments/decrements the boundary value. This overflows when the value is at the type limit (e.g., greaterThan(INT64_MAX) computes INT64_MAX + 1, which wraps to INT64_MIN, creating a range that matches everything instead of nothing). Guard against overflow by returning AlwaysFalse (or IsNull when nulls are allowed) when the boundary is at the type limit. This fixes incorrect query results for filters like WHERE col > 9223372036854775807. Differential Revision: D101039167
Build Impact AnalysisSelective Build Targets (building these covers all 386 affected)Total affected: 386/567 targets Affected targets (386)Directly changed (10)
Transitively affected (376)
Fast path • Graph from main@ab3eea6015c1dc0c2f36864080c02d03859546be |
peterenescu
added a commit
to peterenescu/velox
that referenced
this pull request
Apr 17, 2026
…cubator#17216) Summary: Pull Request resolved: facebookincubator#17216 When converting exclusive bounds to inclusive bounds for BigintRange, HugeintRange, and TimestampRange filters, the code unconditionally increments/decrements the boundary value. This overflows when the value is at the type limit (e.g., greaterThan(INT64_MAX) computes INT64_MAX + 1, which wraps to INT64_MIN, creating a range that matches everything instead of nothing). Guard against overflow by returning AlwaysFalse (or IsNull when nulls are allowed) when the boundary is at the type limit. This fixes incorrect query results for filters like WHERE col > 9223372036854775807. Differential Revision: D101039167
peterenescu
force-pushed
the
export-D101039167
branch
from
053741e to
537d721
Compare
Yuhta
approved these changes
Apr 17, 2026
peterenescu
force-pushed
the
export-D101039167
branch
from
537d721 to
ecc7597
Compare
peterenescu
added a commit
to peterenescu/velox
that referenced
this pull request
Apr 20, 2026
…cubator#17216) Summary: When converting exclusive bounds to inclusive bounds for BigintRange, HugeintRange, and TimestampRange filters, the code unconditionally increments/decrements the boundary value. This overflows when the value is at the type limit (e.g., greaterThan(INT64_MAX) computes INT64_MAX + 1, which wraps to INT64_MIN, creating a range that matches everything instead of nothing). Guard against overflow by returning AlwaysFalse (or IsNull when nulls are allowed) when the boundary is at the type limit. This fixes incorrect query results for filters like WHERE col > 9223372036854775807. Reviewed By: Yuhta Differential Revision: D101039167
peterenescu
added a commit
to peterenescu/velox
that referenced
this pull request
Apr 20, 2026
…cubator#17216) Summary: When converting exclusive bounds to inclusive bounds for BigintRange, HugeintRange, and TimestampRange filters, the code unconditionally increments/decrements the boundary value. This overflows when the value is at the type limit (e.g., greaterThan(INT64_MAX) computes INT64_MAX + 1, which wraps to INT64_MIN, creating a range that matches everything instead of nothing). Guard against overflow by returning AlwaysFalse (or IsNull when nulls are allowed) when the boundary is at the type limit. This fixes incorrect query results for filters like WHERE col > 9223372036854775807. Reviewed By: Yuhta Differential Revision: D101039167
peterenescu
force-pushed
the
export-D101039167
branch
from
ecc7597 to
87b1617
Compare
…cubator#17216) Summary: Pull Request resolved: facebookincubator#17216 When converting exclusive bounds to inclusive bounds for BigintRange, HugeintRange, and TimestampRange filters, the code unconditionally increments/decrements the boundary value. This overflows when the value is at the type limit (e.g., greaterThan(INT64_MAX) computes INT64_MAX + 1, which wraps to INT64_MIN, creating a range that matches everything instead of nothing). Guard against overflow by returning AlwaysFalse (or IsNull when nulls are allowed) when the boundary is at the type limit. This fixes incorrect query results for filters like WHERE col > 9223372036854775807. Reviewed By: Yuhta Differential Revision: D101039167
peterenescu
force-pushed
the
export-D101039167
branch
from
87b1617 to
9efd125
Compare
|
This pull request has been merged in f1c6510. |
shrshi
pushed a commit
to patdevinwilson/velox
that referenced
this pull request
Apr 23, 2026
…cubator#17216) Summary: Pull Request resolved: facebookincubator#17216 When converting exclusive bounds to inclusive bounds for BigintRange, HugeintRange, and TimestampRange filters, the code unconditionally increments/decrements the boundary value. This overflows when the value is at the type limit (e.g., greaterThan(INT64_MAX) computes INT64_MAX + 1, which wraps to INT64_MIN, creating a range that matches everything instead of nothing). Guard against overflow by returning AlwaysFalse (or IsNull when nulls are allowed) when the boundary is at the type limit. This fixes incorrect query results for filters like WHERE col > 9223372036854775807. Reviewed By: Yuhta Differential Revision: D101039167 fbshipit-source-id: fdaddc66c7fb91c079c3dab136b76fc1eafead6e
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Summary:
When converting exclusive bounds to inclusive bounds for BigintRange, HugeintRange, and TimestampRange filters, the code unconditionally increments/decrements the boundary value. This overflows when the value is at the type limit (e.g., greaterThan(INT64_MAX) computes INT64_MAX + 1, which wraps to INT64_MIN, creating a range that matches everything instead of nothing). Guard against overflow by returning AlwaysFalse (or IsNull when nulls are allowed) when the boundary is at the type limit. This fixes incorrect query results for filters like WHERE col > 9223372036854775807.
Reviewed By: Yuhta
Differential Revision: D101039167