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.

Sign up for GitHub

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

Jump to bottom

Use-after-free in FunctionSpecializationPass #52821

Closed
christetreault-llvm opened this issue Dec 21, 2021 · 4 comments
Closed

Use-after-free in FunctionSpecializationPass #52821

christetreault-llvm opened this issue Dec 21, 2021 · 4 comments
Assignees
@sjoerdmeijer
Labels
bug Indicates an unexpected problem or unintended behavior tools:opt

Comments

@christetreault-llvm
Copy link
Contributor

There is a use-after-free issue in FunctionSpecializationPass. In tryToReplaceWithConstant, After the replacement has happened, the code deletes the newly-replaced instruction. However, dangling pointers to the deleted instruction remain in SCCPInstVisitor::AnalysisResults. AnalysisResults is a map from Function * to the results of various analysis passes. As FunctionSpecializationPass continues to run, it may attempt to dereference this dangling pointer. The result of this is a very rare segfault.

If compiling opt with address sanitizer, asan will catch the use-after-free. I've attached a reduced (but unfortunately still huge) bitcode test case that, when opt is compiled to use asan, will reproduce the issue. This bitcode reproduces the use-after-free as-of commit 55c71c9eac9bc7f956a05fa9258fad4f86565450. I used bugpoint to reduce this test case, and while the original case reproduces the issue in both my downstream, and upstream opt, the reduced test case no longer reproduces the issue in my downstream. I'll upload the original test case if the reduced case does not reproduce the issue. I will also attach the output of asan on my machine.

PLEASE NOTE: This test case is derived from compiling GCC. This code should not be the basis for any test case that is committed to the project as it will be a GPL violation.

asan_dump.txt
bugpoint reduced.zip
original case.zip
@christetreault-llvm christetreault-llvm added bug Indicates an unexpected problem or unintended behavior tools:opt labels Dec 21, 2021
@fhahn
Copy link
Contributor

fhahn commented Dec 21, 2021

cc @sjoerdmeijer

@sjoerdmeijer
Copy link
Collaborator

Thanks for the report and also for copying me in.
I am going to take a look at this!

@sjoerdmeijer sjoerdmeijer self-assigned this Dec 22, 2021
@labrinea
Copy link
Collaborator

labrinea commented Jan 27, 2022 •
edited

Turning the instance variable named "Condition" of the class PredicateBase in llvm/include/llvm/Transforms/Utils/PredicateInfo.h from Value * to WeakVH makes the problem go away, but I am not sure this is the right fix. Here's a patch: https://reviews.llvm.org/D118591

labrinea added a commit that referenced this issue Feb 2, 2022
@labrinea
[Function Specialisation] Fix use after free
438a81a 
This is a fix for a use-after-free found by the address sanitizer when
compiling GCC: #52821

The Function Specialization pass may remove instructions, cached
inside the PredicateBase class, which are later being dereferenced
from the SCCPInstVisitor class. To prevent the dangling references
I am lazily deleting the dead instructions after the Solver has run.

Differential Revision: https://reviews.llvm.org/D118591
@labrinea
Copy link
Collaborator

labrinea commented Feb 6, 2022

The sanitizer build https://lab.llvm.org/buildbot/#/builders/168/builds/4555 succeeded. I am closing this issue.

@labrinea labrinea closed this as completed Feb 6, 2022
mem-frob pushed a commit to draperlaboratory/hope-llvm-project that referenced this issue Oct 7, 2022
@labrinea
[Function Specialisation] Fix use after free
df697f8 
This is a fix for a use-after-free found by the address sanitizer when
compiling GCC: llvm/llvm-project#52821

The Function Specialization pass may remove instructions, cached
inside the PredicateBase class, which are later being dereferenced
from the SCCPInstVisitor class. To prevent the dangling references
I am lazily deleting the dead instructions after the Solver has run.

Differential Revision: https://reviews.llvm.org/D118591
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@sjoerdmeijer sjoerdmeijer

Labels
bug Indicates an unexpected problem or unintended behavior tools:opt
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@fhahn @labrinea @sjoerdmeijer @christetreault-llvm