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

vk: Use-after-free coverage #8273

Merged
merged 3 commits into from
Dec 12, 2024
Merged

vk: Use-after-free coverage #8273

merged 3 commits into from
Dec 12, 2024

Conversation

poweifeng
Copy link
Contributor

To allow for use-after-free discovery with ref-counting, we keep a bit to indicate whether the handle is considered destroyed by Filament. We assert against "cast"-ing a destroyed handle.

@poweifeng poweifeng added the internal Issue/PR does not affect clients label Nov 14, 2024
Comment on lines 63 to 67
if (UTILS_UNLIKELY(ptr->isHandleConsideredDestroyed())) {
FILAMENT_CHECK_PRECONDITION(!ptr->isHandleConsideredDestroyed())
<< "Handle id=" << ptr->id << " (" << getTypeStr(ptr->restype)
<< ") is being used after it has been freed";
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you don't need the if here, FILAMENT_CHECK_PRECONDITION already does all the likely/unlikely shenanigans

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was trying to avoid hitting the switch in getTypeStr unless necessary, hence the roundabout logic here.
Do you think it's worth it or not? (or maybe it just going to be speculatively executed anyways?).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, FILAMENT_CHECK_PRECONDITION is pretty sick. If the condition is false, it will not execute at all what comes after the <<. I know it's magic.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@poweifeng poweifeng force-pushed the pf/vk-handle-use-after-free branch from 8e7cc08 to 3e6ceaa Compare November 14, 2024 06:48
@poweifeng
Copy link
Contributor Author

no longer needed

@poweifeng poweifeng closed this Nov 15, 2024
@poweifeng poweifeng reopened this Nov 18, 2024
@poweifeng
Copy link
Contributor Author

Accidentally closed.

To allow for use-after-free discovery with ref-counting, we keep
a bit to indicate whether the handle is considered destroyed by
Filament. We assert against "cast"-ing a destroyed handle.
@poweifeng poweifeng force-pushed the pf/vk-handle-use-after-free branch from 3e6ceaa to e17f340 Compare December 5, 2024 23:56
@poweifeng poweifeng enabled auto-merge (squash) December 12, 2024 00:43
@poweifeng poweifeng merged commit 23847c4 into main Dec 12, 2024
12 checks passed
@poweifeng poweifeng deleted the pf/vk-handle-use-after-free branch December 12, 2024 00:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
internal Issue/PR does not affect clients
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants