-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
GH-45180: [C++][Fuzzing] Fix Negation bug discovered by fuzzing #45181
base: main
Are you sure you want to change the base?
Conversation
|
Can you post the original backtrace? IMHO, Decimal32 and Decimal64 are not supposed to hold a number that large in the first place. |
@pitrou I agree, they aren't supposed to hold values that large. Which is why this was found during fuzzing rather than regular testing I suppose. The original stacktrace shows that the issue was encountered via the
|
In this case I think the safety checks deserve to be in |
(also should check how Decimal128 and Decimal256 behave in similar cases?) |
Are you thinking just a simple |
both Decimal128 and Decimal256 use the |
I was thinking that indeed. However, we may also want to make Negate safe if it's safe in Decimal128/256. But this means we might have to move the |
@pitrou Current version work for you? |
@zeroshade Can you open a PR to add the regression file in https://github.com/apache/arrow-testing/tree/master/data/arrow-ipc-file ? It will then get picked up by the ASAN/UBSAN CI job. |
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.
LGTM, but should update the arrow-testing submodule once the regression file is checked in there.
Added apache/arrow-testing#104 though I still wasn't able to reproduce the issue with the downloaded clusterfuzz file. I only worked it out by reading through the reported stack trace. |
From this OSS-Fuzz issue: https://issues.oss-fuzz.com/issues/371239168 Fixed with apache/arrow#45181
Unfortunately that can depend on the compiler version and other details. But it's still good to have it somewhere. |
Rationale for this change
If the value for Decimal32 or Decimal64 is
INT32_MIN
orINT64_MIN
respectively, then UBSAN reports an issue when calling Negate on them due to overflow.What changes are included in this PR?
Have the
Negate
methods of Decimal32 and Decimal64 usearrow::internal::SafeSignedNegate
.Are these changes tested?
Unit tests were added for both cases which were able to reproduce the problem when UBSAN was on without the fix.
Are there any user-facing changes?
No.