Skip to content
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

Invalid Shift at FastHufDecoder (72367575) #268

Closed
Google-Autofuzz opened this issue Feb 13, 2018 · 0 comments
Closed

Invalid Shift at FastHufDecoder (72367575) #268

Google-Autofuzz opened this issue Feb 13, 2018 · 0 comments
Labels
Bug A bug in the source code

Comments

@Google-Autofuzz
Copy link

Hello OpenEXR team,

As part of our fuzzing efforts at Google, we have identified an issue affecting
OpenEXR (tested with revision develop 165dcea).

To reproduce, we are attaching a Dockerfile which compiles the project with
LLVM, taking advantage of the sanitizers that it offers. More information about
how to use the attached Dockerfile can be found here:
https://docs.docker.com/engine/reference/builder/

TL;DR instructions:

  • mkdir project
  • cp Dockerfile /path/to/project
  • docker build --no-cache /path/to/project
  • docker run -it image_id_from_docker_build

From another terminal, outside the container:
docker cp /path/to/attached/reproducer running_container_hostname:/fuzzing/reproducer
(reference: https://docs.docker.com/engine/reference/commandline/cp/)

And, back inside the container:
/fuzzing/repro.sh /fuzzing/reproducer

Alternatively, and depending on the bug, you could use gcc, valgrind or other
instrumentation tools to aid in the investigation. The sanitizer error that we
encountered is here:

ImfFastHuf.cpp:377:48: runtime error: shift exponent 64 is too large for 64-bit type 'Int64' (aka 'unsigned long')
SUMMARY: AddressSanitizer: undefined-behavior ImfFastHuf.cpp:377:48 in 

We will gladly work with you so you can successfully confirm and reproduce this
issue. Do let us know if you have any feedback surrounding the documentation.

Once you have reproduced the issue, we'd appreciate to learn your expected
timeline for an update to be released. With any fix, please attribute the report
to "Google Autofuzz project".

We are also pleased to inform you that your project is eligible for inclusion to
the OSS-Fuzz project, which can provide additional continuous fuzzing, and
encourage you to investigate integration options.

Don't hesitate to let us know if you have any questions!

Google AutoFuzz Team
artifacts_72367575.zip

@cary-ilm cary-ilm added the Bug A bug in the source code label Jun 13, 2019
kdt3rd added a commit to kdt3rd/openexr that referenced this issue Aug 13, 2019
… decoder

Technically, doing a logical right shift by the number of bits (or more)
of a number is undefined behaviour. gcc / x86 seems to do (v >>
(shift%bits)), meaning that a right shift of 64 would end up as a right
shift of 0 on a uint64_t value. However, other platforms may shift by
the full number of bits and produce and output 0, not the input. Instead
of leaving this ambiguity, force the 0th value to be manually unrolled /
extracted and to do what was there (and validated by test) as an
undefined behaviour as a more explicit operation.

Signed-off-by: Kimball Thurston <kdt3rd@gmail.com>
@kdt3rd kdt3rd closed this as completed in 2f33f0f Aug 15, 2019
DominicJacksonBFX pushed a commit to boris-fx/mocha-openexr that referenced this issue Jun 22, 2022
… decoder

Technically, doing a logical right shift by the number of bits (or more)
of a number is undefined behaviour. gcc / x86 seems to do (v >>
(shift%bits)), meaning that a right shift of 64 would end up as a right
shift of 0 on a uint64_t value. However, other platforms may shift by
the full number of bits and produce and output 0, not the input. Instead
of leaving this ambiguity, force the 0th value to be manually unrolled /
extracted and to do what was there (and validated by test) as an
undefined behaviour as a more explicit operation.

Signed-off-by: Kimball Thurston <kdt3rd@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug A bug in the source code
Projects
None yet
Development

No branches or pull requests

2 participants